On 01/04, bartosz.rabiega@ovhcloud.com wrote:

Oh thanks for the clarification!

I'm particularly interested in native multipath (ANA). Are there any plans to have a mechanism for updating/replacing failed paths? E.g. in case when one of the backend paths dies and has to be replaced with a new one - completely new target (let's say cinder driver exposes new path in place of the failed one).

Is there a way to participate in the development?

BR

Hi,

There is no plan to provide a generic mechanism to create new paths. Traditional storage systems have N interfaces, and the cinder driver usually exports and maps volumes on ALL available interfaces, so there is no additional path that can be created on the storage system if one of the existing paths fail.

If I remember correctly, for non traditional SDS storage systems that can potentially create additional copies of the volume on a different location and add a new path, the current approach we are taking is having an agent on the system that can talk directly with the storage and update the local nvme circumventing Cinder.

Did you have a specific storage in mind? Right now I believe both lightos and Kioxia have that approach.

Today I've started on adding multipathing support to LVM with nvmet so I can test the os-brick multipathing patch.

Regarding participating in the development, PLEASE DO! All contributions are welcome (including cloud providers bringing their ideas and concerns).

There are upstream guides [1] on how to contribute, but you can always just drop by the Cinder team IRC and video meetings [2] and it just so happens that next week we are going to have the PTG [3].

The PTG is a great opportunity to hear about the current and future OpenStack development efforts, as well as bring topics up for discussion.

The Cinder team will be meeting Tuesday to Friday from 13:00 to 17:00 UTC each day. You can see in the topics [4] and schedule [5] that on Friday we'll be discussing about existing NVMe-oF issues.

Which makes me think that we should change the topic to a more generic one, such as "NVMe-oF efforts", since we'll probably discuss the ongoing multipathing effort as well.

Registration is free [6] and you don't have to attend all days, so I'm looking forward to see you there. ;-)

Cheers, Gorka.

[1]: https://wiki.openstack.org/wiki/How_To_Contribute [2]: https://wiki.openstack.org/wiki/CinderMeetings [3]: https://www.openstack.org/ptg/ [4]: https://etherpad.opendev.org/p/zed-ptg-cinder [5]: https://ethercalc.openstack.org/crz6qdm7fq0v [6]: https://openinfra-ptg.eventbrite.com/

On 4/1/22 11:03, Gorka Eguileor wrote:

...

On 01/04, bartosz.rabiega@ovhcloud.com wrote:

...

Hello,

I'm trying to figure out how the new feature of Yoga works:

"The libvirt driver now allows using Native NVMeoF multipathing for NVMeoF connector, via the configuration attribute in nova-cpu.conf [libvirt]/volume_use_multipath, defaulting to False (disabled)."

https://review.opendev.org/c/openstack/nova/+/823941

It's said that this config value enables native NVMeoF multipathing, but I can't see any support for such configuration in os-brick connector.

https://github.com/openstack/os-brick/blob/master/os_brick/initiator/connect...

Am I missing something?

BR BR

Hi,

You are not missing anything.

Maybe the wording of the nova release note could have been a bit more clear, because what nova has now is the ability to let NVMe-oF use multipathing (once it becomes available in os-brick) for Cinder drivers that support it...

There are 2 kinds of multipathing possible with NVMe-oF:

• Native (ANA)
• Device Mapper (same as with iSCSI an FC)

The team is currently working on adding NVMe-oF native multipathing to os-brick [1], and the DM option will be available later, so it's not available on Yoga.

Once it becomes available in os-brick, Cinder drivers will need to be updated to use the newer connection information format (except the Kioxia driver that already uses it).

Cheers, Gorka.