[nova][cinder][ops] question/confirmation of legacy vol attachment migration
On 10/10/2019 2:20 PM, Sean McGinnis wrote:
> 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.
It's unrelated to what I'm trying to solve, but could a cinder tempest
plugin test be added which hits the initialize_connection API multiple
times without changing host connector and assert the driver is doing the
correct thing, whatever that is? Maybe it's just asserting that the
connection_info returned from the first call is identical to subsequent
calls if the host connector dict input doesn't change?
> But you can create as many attachment objects in the database as you want.
But you have to remember to delete them otherwise the volume doesn't
leave in-use status even if the volume is detached from the server, so
there is attachment counting that needs to happen somewhere (I know
cinder does it, but part of that is also on the client side - nova in
this case). With the legacy attach flow nova would being_detaching,
terminate_connection and then call os-detach and I suppose os-detach
could puke if the client hadn't done the attachment cleanup properly,
i.e. hadn't called terminate_connection. With the v3 attachments flow we
don't have that, we just create attachment, update it with host
connector and then complete it. On detach we just delete the attachment
and if it's the last one the volume is no longer in-use. I'm not
advocating adding another os-detach-like API for the v3 attachment flow,
just saying it's an issue if the client isn't aware of all that.