[openstack-dev] [nova][cinder] Update (swap) of multiattach volume should not be allowed

Matt Riedemann mriedemos at gmail.com
Wed Jun 6 19:58:26 UTC 2018


Here is the nova patch for those following along:

https://review.openstack.org/#/c/572790/

On 6/6/2018 9:07 AM, Jay Pipes wrote:
> 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
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 

Thanks,

Matt



More information about the OpenStack-dev mailing list