[nova][cinder][ops] question/confirmation of legacy vol attachment migration

Lee Yarwood lyarwood at redhat.com
Wed Apr 22 09:25:42 UTC 2020


On 21-04-20 18:43:29, Lee Yarwood wrote:
> On 12-12-19 12:49:57, Brett Milford wrote:
> > On Tue, Dec 10, 2019 at 11:15 PM Gorka Eguileor <geguileo at redhat.com> wrote:
> > >
> > > On 06/12, Brett Milford wrote:
> > > > On Fri, Nov 22, 2019 at 3:54 AM Matt Riedemann <mriedemos at gmail.com> wrote:
> > > > >
> > > > > On 10/17/2019 5:24 AM, Gorka Eguileor wrote:
> > > > > > I stand by my initial recommendation, being able to update the existing
> > > > > > attachment to add the connection information from Nova.
> > > > >
> > > > > OK, thanks for the input and thoughtfulness on this. I've abandoned my
> > > > > change since I'm not going to be pushing this boulder anymore but left
> > > > > notes in the change in case someone else wants to pick it up some day.
> > > > >
> > > > > Note to nova cores: this means we'll have legacy volume attachment
> > > > > compat code around forever.
> > > > >
> > > > > --
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Matt
> > > > >
> > > >
> > > > Hi Groka, Cinder & Nova devs,
> > > >
> > > > Following up this thread from the context of
> > > > https://review.opendev.org/#/c/579004/
> > > >
> > > > To summarise the discussion:
> > > >   - initialize_connection shouldn't be called more than once, as it
> > > > may mess up some drivers.
> > > >   - To (safely) refresh connection_info a new api for cinder is required.
> > >
> > > Hi,
> > >
> > > It may be a new API or a modification of one of the existing ones.
> > >
> > >
> > > >   - a patch to nova, such as #579004 could make a call to this new api
> > > > to refresh connection info on events such as reboot.
> > > >
> > > > Is there any other context to this issue I've missed or an alternate
> > > > path to solving this?
> > > >
> > > > Does the creation of a new api for cinder have any implications for
> > > > being able to backport this patch for nova?
> > > >
> > >
> > > I don't think backporting it in Nova would do us much good, since the
> > > Cinder code would not be backportable (it's a new feature, not a bug
> > > fix).
> > >
> > >
> > > > What would be the process for me to kick off this work?
> > > >
> > >
> > > You should propose a Cinder spec [1] for your work and you may provide a
> > > WIP patch to Cinder at the same time, though depending on the review you
> > > may have to completely change that code later.
> > >
> > > Cheers,
> > > Gorka.
> > >
> > > [1]: https://opendev.org/openstack/cinder-specs
> > >
> > > > Thanks for your help,
> > > > Brett (bcm)
> > > > --
> > > > ❯ brett
> > > >
> > >
> > 
> > Cheers Matt, Groka, I thought this might be the case.
> 
> Did anyone on the Cinder side pickup the connection_info refresh or
> export(?) to attachment migration work in the end here? I can't see
> anything but just wanted to ask before proposing something for V.

Assuming no one is working on this, what about the following that
provides a backportable hackaround to specifically address the ceph MON
update issue *and* new APIs in V to address the v2 to v3 migration flow.

- Have the c-vol drivers return a flag in their connection_info to
  indicate when calls to intialize_connection/attachment_update are
  idempotent. This will allow n-cpu to know here when it's safe to call
  intialize_connection/attachment_update to fully refresh the
  connection_info. Both changes should be backportable.

- For the specific ceph MON update issue here, introduce a backportable
  workaround configurable that forces a refresh of the connection_info
  for running instances somehow, either through a periodic job, start up
  of n-cpu or some other trigger.

- Introduce a new c-api v3 API to refresh an attachments
  connection_info, essentially do all of the above on the Cinder side
  and have n-cpu call that instead of checking connection_info for the
  idempotent flag. This wouldn't be backportable.

- Introduce a new n-api API to trigger the refresh of a specific
  attachments connection_info via the above c-api API. This wouldn't be
  backportable.

- Introduce a new c-api v3 attachments action (os-migrate) API to
  migrate from v2 exports to v3 attachments using the above refresh
  logic, again on the Cinder side.

- Finally remove the idempotent connection_info flag from c-vol and
  workaround option from n-cpu.

Thoughts?

-- 
Lee Yarwood                 A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200422/1ae78e71/attachment.sig>


More information about the openstack-discuss mailing list