Open Stack

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.

-- 

Thanks,

Matt