Cinder-volume/openstack-hypervisor storage arrays support

  • name: cinder-volume/openstack-hypervisor

  • description:

    • The Cinder Volume snap contains the Volume handler from the OpenStack cinder service. This service is responsible for spawning volumes from external backends, such as Ceph, PureStorage, Hitachi, Dell SC…
    • The OpenStack-Hypervisor snap contains the compute bits (mainly Libvirtd and Nova-Compute) which both needs access to these permissions to be able to mount and use the volumes prepared by Cinder Volume snap.
  • snapcraft:

  • upstream:

  • upstream-relation: Cinder Volume snap and OpenStack Hypervisor are managed by the Canonical OpenStack team. We are a downstream distribution of the OpenStack project. This work is a part of the upstream Sunbeam work.

  • interfaces:

    • iscsi-initiator:

      • request-type: auto-connection

      • reasoning: Required to access iSCSI configuration files (/etc/iscsi/initiatorname.iscsi, /etc/iscsi/iscsid.conf) and establishing iSCSI connections to storage backends like PureStorage, Hitachi, and Dell SC arrays. Many enterprise storage systems use iSCSI as the primary protocol for volume attachment.

    • nvme-control:

      • request-type:auto-connection

      • reasoning: Required to read NVMe host identification files (/etc/nvme/hostnqn, /etc/nvme/hostid) which are required for NVMe-over-TCP connections to modern storage arrays. Enterprise storage backends increasingly support NVMe protocols for high-performance volume access.

    • dm-multipath:

      • request-type: auto-connection

      • reasoning: Required to allow mounting iscsi (or other kind of block devices) into a multipath setup for increased IO-performance and reliability. This is a common setup for production environment connecting to backends.

Opening as a single requests for these two snaps as granting this only makes sense when both these snaps have access.

The role of cinder-volume is uniquely to communicate with the storage array, eventually mounting the image locally if an OS image needs to be burned on the volume or the volume needs to be cleaned up. All these means the cinder-volume snap needs the permissions to mount the remote volume locally and perform IO operations on it.

The role of the openstack-hypervisor is to mount locally these volume and attach them to the instances, allowing these instances to be based of remote storage for either increased performance or reliability.

This request has been added to the queue for review by the @reviewers team.

Considering that these interfaces where primary designed with this use case in mind (See Cinder-volume auto-connect iscsi/nvme system files ), +1 from me for granting cinder-volume and openstack-hypervisor auto-connection to iscsi-initiator, nvme-control and dm-multipath interfaces (#voteFor)

Agree with the reason, +1 from my end too for the auto-connection of dm-multipath, nvme-control and iscsi-initiator interfaces to these snaps

#voteFor

Hello! Given the reasoning mentioned above, this request is a good candidate for fast-track. +1 (#voteFor) from me for the auto-connection of iscsi-initiator, nvme-control, and dm-multipath for both the cinder-volume and openstack-hypervisor snaps.

Thanks, a fast-track would be appreciated.

Hey @gboutry

That was the plan but I just realized that review-tools didn’t support these interfaces. The [MR](Merge into master : add-dm-multipaht-iscsi-initiator-nvme-control-interfaces : lp:~jslarraz/review-tools : Git : Code : review-tools) to support them was already merged and we will create a new review-tools release very soon.

Hello @jslarraz, any news as to when this can be moved forward?

Hey @gboutry

New review-tools release was created yesterday and store team folks said they will deploy it next week