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

Sean McGinnis sean.mcginnis at gmx.com
Thu Oct 10 19:20:37 UTC 2019


> > >
> > > a) create new attachment with host connector
> > This is a good idea in itself, but it's not taking into account weird
> > behaviors that some Cinder drivers may have when you call them twice to
> > initialize the connection on the same host.  Some drivers end up
> > creating a different mapping for the volume instead of returning the
> > existing one; we've had bugs like this before, and that's why Nova made
> > a change in its live instance migration code to not call
> > intialize_connection on the source host to get the connection_info for
> > detaching.
>
> Huh...I thought attachments in cinder were a dime a dozen and you could
> create/delete them as needed, or that was the idea behind the new v3
> attachments stuff. It seems to at least be what I remember John Griffith
> always saying we should be able to do.
>
> Also if you can't refresh the connection info on the same host then a change
> like this:
>
> https://review.opendev.org/#/c/579004/
>
> Which does just that - refreshes the connection info doing reboot and start
> instance operations - would break on those volume drivers if I'm following
> you.
>

Creating attachements, using the new attachments API, is a pretty low overhead
thing. The issue is/was with the way Nova was calling initialize_connection
expecting it to be an idempotent operation.

I think we've identified most drivers that had an issue with this. It wasn't a
documented assumption on the Cinder side, so I remember when we first realized
that was what Nova was doing, we found a lot of Cinder backends that had issues
with this.

With initialize_connection, at least how it was intended, it is telling the
backend to create a new connection between the storage and the host. So every
time initialize_connection was called, most backends would make configuration
changes on the storage backend to expose the volume to the requested host.
Depending on how that backend worked, this could result in multiple separate
(and different) connection settings for how the host can access the volume.

Most drivers are now aware of this (mis?)use of the call and will first check
if there is an existing configuration and just return those settings if it's
found. There's no real way to test and enforce that easily, so making sure all
drivers including newly added ones behave that way has been up to cores
remembering to look for it during code reviews.

But you can create as many attachment objects in the database as you want.

Sean



More information about the openstack-discuss mailing list