On 4/11/2017 5:35 PM, Matt Riedemann wrote:
I'm reading through mgagne's spec to support attached volume size
extension callbacks in Nova [1] and the question that comes up is what
happens when the backend compute does not support this, either because
it's too old (Ocata) or the virt driver does not support the event?

The spec is targeted at libvirt to use os-brick, but the hyper-v driver
is also using os-brick since Ocata, and the Windows connector support
the extend_volume operation, so that should work.

I don't know about powervm, vmware or xen though.

This is not discoverable at the moment, for the end user or cinder, so
I'm trying to figure out what the failure mode looks like.

This all starts on the cinder side to extend the size of the attached
volume. Cinder is going to have to see if Nova is new enough to handle
this (via the available API versions) before accepting the request and
resizing the volume. Then Cinder sends the event to Nova. This is where
it gets interesting.

On the Nova side, if all of the computes aren't new enough, we could
just fail the request outright with a 409. What does Cinder do then?
Rollback the volume resize?

But let's say the computes are new enough, but the instance is on a
compute that does not support the operation. Then what? Do we register
an instance fault and put the instance into ERROR state? Then the admin
would need to intervene.

Are there other ideas? Until we have capabilities (info) exposed out of
the API we're stuck with questions like this.

[1] https://review.openstack.org/#/c/453272/


I guess we also have the instance action events. So we could avoid putting the instance into ERROR state but record an instance action event that the extend volume event failed on the compute, so at least the user/admin could figure out why it didn't change on the nova side.

What they do after that I'm not sure. Would detaching and then re-attaching the now resized volume fix it?

--

Thanks,

Matt

__________________________________________________________________________
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

Reply via email to