Open Stack

On 06/06/2018 10:02 AM, Matt Riedemann wrote:
> 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.

+10

-jay