openstack/sushy-tools
Code Issues Proposed changes

Cleanup usage of 'simulator' and 'cloud-backed' in docs

Browse Source 
Followup patch to rephrase 'cloud-backed' to indicate that
sushy-emulator is backed by libvirt or OpenStack cloud.

Change to use 'emulator' instead of 'simulator' across the docs.
As these emulators are used to substitute real Redfish BMC and
work to have same input/output as Redfish BMC, 'emulator' is the
term to use.

Change-Id: Ic2ca3f4d6b485085d1fc0300f5e697ac0473982f
This commit is contained in:
Aija Jaunteva 2018-07-11 13:34:48 +03:00
parent 9900ad87da
commit 44c4ad3787
3 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.rst
View File

@ -7,7 +7,7 @@ development and testing of the Redfish protocol implementations and,
in particular, Sushy library (https://docs.openstack.org/sushy/).
The package ships two simulators - static Redfish responder and
cloud-backed virtual Redfish BMC.
virtual Redfish BMC that is backed by libvirt or OpenStack cloud.
The static Redfish responder is a simple REST API server which
responds the same things to client queries. It is effectively

14
doc/source/admin/index.rst
View File

@ -1,11 +1,11 @@
Configuring simulators
======================
Configuring emulators
=====================
Running simulators in background
--------------------------------
Running emulators in background
-------------------------------
The simulators run as interactive processes attached to the
The emulators run as interactive processes attached to the
terminal by default. You can create a systemd service to run the
emulators in background.
For each emulator create a systemd unit file and
@ -22,8 +22,8 @@ adjust arguments as necessary, for example::
StandardOutput=syslog
StandardError=syslog
If you want to run simulators with different configuration, for example,
``sushy-static`` simulator with different mockup files, then create a new
If you want to run emulators with different configuration, for example,
``sushy-static`` emulator with different mockup files, then create a new
systemd unit file.
You can also use ``gunicorn`` to run ``sushy-emulator``, for example::

12
doc/source/user/index.rst
View File

@ -1,9 +1,9 @@
Using Redfish simulators
========================
Using Redfish emulators
=======================
The sushy-tools package includes two simulators - static Redfish responder
and cloud-backed Redfish proxy.
The sushy-tools package includes two emulators - static Redfish responder
and virtual Redfish BMC that is backed by libvirt or OpenStack cloud.
Static Redfish BMC
------------------
@ -25,7 +25,7 @@ includes Redfish content mocks for Redfish 1.0.0.
unzip -d mockups DSP2043_1.0.0.zip
sushy-static -m mockups/public-rackmount
Once you have the static simulator running, you can use it as it was a
Once you have the static emulator running, you can use it as it was a
read-only bare-metal controller listening at *localhost:8000* (by default):
.. code-block:: bash
@ -129,7 +129,7 @@ baremetal machines. This setup is known under the name of
`OpenStack Virtual Baremetal <http://openstack-virtual-baremetal.readthedocs.io/en/latest/>`_.
We will largely re-use its OpenStack infrastructure and configuration
instructions. After all, what we are trying to do here is to set up the
Redfish simulator alongside the
Redfish emulator alongside the
`openstackvbmc <https://docs.openstack.org/tripleo-docs/latest/install/environments/virtualbmc.html>`_
tool which is used for exactly the same purpose at OVB with the only
difference that it works over the *IPMI* protocol as opposed to *Redfish*.