This patch is intended to make the handle of the resources identification more flexible in the library. Prior to this patch the library had some assumptions about the path of a given resource and tried to build such paths within it. Turns out that it's not that simple, the Redfish specification does allow things like resources from a different authority to be registered in a different controller [0]. I quote: "Resources within the same authority as the request URI shall be represented according to the rules of path-absolute defined by that specification. That is, they shall always start with a single forward slash ("/"). Resources within a different authority as the request URI shall start with a double-slash ("//") followed by the authority and path to the resource." That means that, members of a collection could be either: "/redfish/v1/Systems/12345" or "//another-service.com/redfish/v1/Systems/12345" This breaks many of the assumptions we had before of how to handle these resources from the controller. So, this patch is basically making sushy more "dumb" about the location of the resources by not trying to build the URI for it but instead just relying on the URI returned from the members of a collection or other attributes of a specific resource. One example here was the "target" attribute of the #ComputerSystem.Reset reset action, prior to this patch we needed to strip portions of the URI (the /redfish/v1) in order to fit the model that we use to construct the URLs now, that's not needed anymore. Note that, this patch is non-backward compatible and changes the usage of the library but, since we haven't had any release yet (so it's not even alpha or beta, but completely under-development) it seems to be the right time for such a change. [0] http://redfish.dmtf.org/schemas/DSP0266_1.1.html#resource-identifier-property Change-Id: Ia4211ebb3b99f6cc4bd695b5dbea2018d301de33
4.3 KiB
Usage
To use sushy in a project:
import logging
import sushy
# Enable logging at DEBUG level
= logging.getLogger('sushy')
LOG
LOG.setLevel(logging.DEBUG)
LOG.addHandler(logging.StreamHandler())
= sushy.Sushy('http://localhost:8000', username='foo', password='bar')
s
# Get the Redfish version
print(s.redfish_version)
# Instantiate a system object
= s.get_system('/redfish/v1/Systems/437XR1138R2')
sys_inst
# Using system collections
# Instantiate a SystemCollection object
= s.get_system_collection()
sys_col
# Print the ID of the systems available in the collection
print(sys_col.members_identities)
# Get a list of systems objects available in the collection
= sys_col.get_members()
sys_col_insts
# Instantiate a system object, same as getting it directly
# from the s.get_system()
= sys_col.get_member(sys_col.members_identities[0])
sys_inst
# Refresh the system collection object
sys_col.refresh()
# Using system actions
# Power the system ON
sys_inst.reset_system(sushy.RESET_ON)
# Get a list of allowed reset values
print(sys_inst.get_allowed_reset_system_values())
# Refresh the system object
sys_inst.refresh()
# Get the current power state
print(sys_inst.power_state)
# Set the next boot device to boot once from PXE in UEFI mode
sys_inst.set_system_boot_source(sushy.BOOT_SOURCE_TARGET_PXE,=sushy.BOOT_SOURCE_ENABLED_ONCE,
enabled=sushy.BOOT_SOURCE_MODE_UEFI)
mode
# Get the current boot source information
print(sys_inst.boot)
# Get a list of allowed boot source target values
print(sys_inst.get_allowed_system_boot_source_values())
Running a mockup server
Static mockup
Sushy ships a small script at tools/mockup_server.py
that creates a HTTP server to serve any of the Redfish mockups. The
files are static so operations like changing the boot device or the
power state will not have any effect. But that should
be enough for enabling people to test parts of the library. To setup it
do:
Download the .zip containing the Redfish mockups files from https://www.dmtf.org/standards/redfish, for example:
wget https://www.dmtf.org/sites/default/files/standards/documents/DSP2043_1.0.0.zip
Extract it somewhere in the file-system:
unzip DSP2043_1.0.0.zip -d <output-path>
Now run the
mockup_server.py
script:python sushy/tools/mockup_server.py --mockup-files <output-path>/DSP2043-server --port 8000
Libvirt mockup
Sushy also ships a small application at
tools/mockup_server_libvirt
that starts a ReST API that
users can use to interact with virtual machines using the Redfish
protocol. So operations such as changing the boot device or the power
state will actually affect the virtual machines. This allows users to
test the library in a more dynamic way. To setup it do:
tox -elibvirt-simulator
# Or, running with custom parameters
tox -elibvirt-simulator -- --port 8000 --libvirt-uri "qemu:///system"
Note
Installing the dependencies requires libvirt development files. For example, run the following command to install them on Fedora:
sudo dnf install -y libvirt-devel
That's it, now you can test Sushy against the
http://locahost:8000
endpoint.
Enabling SSL
Both mockup servers supports SSL if you want Sushy with it. To set it up, first you need to generate key and certificate files with OpenSSL use following command:
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365
Start the mockup server passing the --ssl-certificate
and --ssl-key
parameters to it to it, for example:
python sushy/tools/mockup_server.py --ssl-key key.pem --ssl-certificate cert.pem --mockup-files <output-path>/DSP2043-server --port 8000
Now to connect with SSL to the
server use the verify
parameter pointing to the certificate
file when instantiating Sushy, for example:
import sushy
# Note the HTTP"S"
= sushy.Sushy('https://localhost:8000', verify='cert.pem', username='foo', password='bar') s