Open Stack

On 01/04, bartosz.rabiega at 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 at 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/connectors/nvmeof.py
> > >
> > > 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.
> >
> >
> > [1]: https://review.opendev.org/c/openstack/os-brick/+/830800
> >
>