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