Open Stack

On Fri, Apr 24, 2015 at 8:40 AM, Peter Penchev <openstack-dev at storpool.com>
wrote:

> Hi,
>
> There are a couple of Tempest volume tests, like
> test_rescued_vm_detach_volume or test_list_get_volume_attachments,
> that either sometimes[0] or always attempt to detach a volume from a
> running instance while the instance could still be keeping it open.
> Unfortunately, this is not completely compatible with the StorPool
> distributed storage driver - in a StorPool cluster, a volume may only
> be detached from a client host (the Nova hypervisor) if there are no
> processes running on the host (e.g. qemu) that keep the volume open.
> This came about as a result of a series of Linux kernel crashes that
> we observed during our testing when a volume containing a filesystem
> was detached while the kernel's filesystem driver didn't expect it to.
>
> Right now, our driver for attaching StorPool volumes (defined in
> Cinder) to Nova instances (proposed in
>
> http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/libvirt-storpool-volume-attach.html
> yet didn't get enough +1/+2's in time for Kilo RC2) tries to detach
> the volume, then waits for a couple of seconds, hoping that any
> processes would have been notified to let it go, then tries again,
> then fails.  Of course, StorPool has a "force detach" option that
> could be used in that case; the problem there is that it might indeed
> lead to some trouble for the instances that will have the volume
> pulled out from under their tiny instance legs.  This could go in the
> "let the operator handle it" category - if we're detaching a volume,
> this supposedly means that the filesystem has already been unmounted
> within the instance... is this a sensible approach?  Should we teach
> our driver to forcibly detach the volume if the second polite attempt
> still fails?
>
>
IMHO, the number one thing to keep in mind when answering this is to keep
the user experience backend agnostic. A user should never have to know what
driver a cloud is using or be forced do do something differently because of
it.

So if the other standard is to allow detaching volumes in use in a way that
doesn't lead to trouble for the instances using the volume, your driver
should do that. If the standard is doing this can lead to trouble for
instances but it is still allowed then adding a forcible detach is
sufficient.



> G'luck,
> Peter
>
> [0] The "sometimes" part: it seems that in some tests, like
> test_list_get_volume_attachments, the order of the "detach volume" and
> "stop the running instance" actions is random, dependent on the order
> in which the Python test framework will execute the cleanup handlers.
> Of course, it might be that I'm misunderstanding something and it is
> completely deterministic and there is another issue at hand...
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150424/8b387f74/attachment.html>