sushy/doc/source/usage.rst
Lucas Alvares Gomes 392a4a6272 Sushy to adhere to the resource identifier portion of the spec
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
2017-03-24 14:28:16 +00:00

4.3 KiB

Usage

To use sushy in a project:

import logging

import sushy

# Enable logging at DEBUG level
LOG = logging.getLogger('sushy')
LOG.setLevel(logging.DEBUG)
LOG.addHandler(logging.StreamHandler())

s = sushy.Sushy('http://localhost:8000', username='foo', password='bar')

# Get the Redfish version
print(s.redfish_version)

# Instantiate a system object
sys_inst = s.get_system('/redfish/v1/Systems/437XR1138R2')


# Using system collections


# Instantiate a SystemCollection object
sys_col = s.get_system_collection()

# 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_insts = sys_col.get_members()

# Instantiate a system object, same as getting it directly
# from the s.get_system()
sys_inst = sys_col.get_member(sys_col.members_identities[0])

# 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,
                                enabled=sushy.BOOT_SOURCE_ENABLED_ONCE,
                                mode=sushy.BOOT_SOURCE_MODE_UEFI)

# 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:

  1. 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
  2. Extract it somewhere in the file-system:

    unzip DSP2043_1.0.0.zip -d <output-path>
  3. 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"
s = sushy.Sushy('https://localhost:8000', verify='cert.pem', username='foo', password='bar')