Open Stack

On 6/6/2018 8:24 AM, Jay Pipes wrote:
> On 06/06/2018 09:10 AM, Artom Lifshitz wrote:
>> I think regardless of how we ended up with this situation, we're still
>> in a position where we have a public-facing API that could lead to
>> data-corruption when used in a specific way. That should never be the
>> case. I would think re-using the already possible 400 response code to
>> update-volume when used with a multi-attach volume to indicate that it
>> can't be done, without a new microversion, would be the cleaned way of
>> getting out of this pickle.
> 
> That's fine, yes.
> 
> I just think it's worth noting that it's a pickle that we put ourselves 
> in due to an ill-conceived feature and Compute API call. And that we 
> should, you know, try to stop doing that. :)
> 
> -jay

If we're going to change something, I think it should probably happen on 
the cinder side when the retype or live migration of the volume is 
initiated and would do the attachment counting there.

So if you're swapping from multiattach volume A to multiattach volume B 
and either has >1 read/write attachment, then fail with a 400 in the 
cinder API.

We can check those things in the compute API when cinder calls the swap 
volume API in nova, but:

1. It's racy - cinder is the source of truth on the current state of the 
attachments.

2. The failure mode is going to be questionable - by the time cinder 
calls nova to swap the volumes on the compute host, the cinder REST API 
has long since 202'ed the response to the user and the best nova can do 
is return a 400 and then cinder has to handle that gracefully and 
rollback. It would be much cleaner if the volume API just fails fast.

-- 

Thanks,

Matt