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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
