Cinder packages should have sysfsutils as a dependency

[Pedro Guimarães]

Running openstack Ussuri + Focal with Cinder HPE 3PAR on Fiber Channel.

When trying to attach volumes or create a volume from an image, it fails with:
https://pastebin.ubuntu.com/p/mwPZhYK5c4/

That is cinder API-level error, but it happens on the client side of the communication.
It is the response of the API call made, requesting for a certain volume operation (so far, seen this with attachment and creating from volume).

That is happening because the properties field of the request is going empty.
It means the client is not populating the API request with the properties field, which would include the connector and an entry for "wwpns".

In the case of the create-volume-from-image
That property field is populated on: https://github.com/openstack/cinder/blob/393c2e4ad90c05ebf28cc3a2c65811d7e1e0bc18/cinder/volume/driver.py#L878

Which in turn, calls the os_brick lib on:
https://github.com/openstack/cinder/blob/393c2e4ad90c05ebf28cc3a2c65811d7e1e0bc18/cinder/volume/volume_utils.py#L1320

This is the os_brick method:
https://github.com/openstack/os-brick/blob/1b2e2295421615847d86508dcd487ec51fa45f25/os_brick/initiator/connectors/fibre_channel.py#L60

And eventually, calls:
https://github.com/openstack/os-brick/blob/1b2e2295421615847d86508dcd487ec51fa45f25/os_brick/initiator/linuxfc.py#L162

If systool is not installed, it will fail but the get_connector_properties handles that and returns an empty properties field instead.

In the case of HPE 3PAR, it expects the standard os_brick linuxfc.py to correctly call the get_fc_hbas method. Then, it sends the result as a request to the cinder API, resulting in the KeyError message as the response.

The linuxfc.py code in the os_brick is a generic handler of Fiber Channel connections.
Sysfsutils is a dependency of that generic handler in os_brick.

Given this issue affects both cinder-volume and nova-compute and standard cinder code on os_bricks uses sysfsutils, I'd recommend we set sysfsutils as prerequisites of both python*-cinderclient and cinder-volume packages.

WORK-AROUND:
The work-around possible so far is to have the cinder backend charm written to install the sysfsutils.
It does not cover the issue for the nova-computes, which also need that package to populate the properties field correctly.
Then, one workaround is to run:

$ juju run --application nova-compute "sudo apt install -y sysfsutils"
$ juju run --application cinder-volume "sudo apt install -y sysfsutils"

[Andre Ruiz (andre-ruiz)]

The charm seems to be installing the package now, according to:

https://opendev.org/openstack/charm-cinder-three-par/src/branch/master/src/charm.py#L52

Considering that both cinder-volume and nova-compute will land on the same baremetals, installing in one is enough for both to use.

[Andre Ruiz (andre-ruiz)]

Unless you don't run cinder-volume + cinder-three-par on all compute nodes... Which turns out to be my case (running 52 instances of the 3par driver was overloading the storage controller and that is not really necessary, just a few are enough).

[Nobuto Murata (nobuto)]

Please see https://bugs.launchpad.net/ubuntu/+source/python-os-brick/+bug/1947063

sysfsutils can be installed by the nova-compute charm by enabling the "use-multipath" option. Also, it's a responsibility of each storage backend charm to install sysfsutils on the Cinder volume units for the time being.