Open Stack

I think Sean and John are in the right direction.  Nova and Cinder need to
be more decoupled in the area of volume attachments.

I think some of the mess here is due to different Cinder backend behavior -
with some Cinder backends you actually attach volumes to a host (e.g., FC,
iSCSI), with some you attach to a VM (e.g., Ceph), and with some you attach
an entire pool of volumes to a host (e.g., NFS).  I think this difference
should all be contained in the Nova drivers that do the attachments.

On Thu, Feb 11, 2016 at 6:06 AM, John Griffith <john.griffith8 at gmail.com>
wrote:

>
>
> On Wed, Feb 10, 2016 at 5:12 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:
>
>> But the issue is, when told to detach, some of the drivers do bad things.
>> then, is it the driver's issue to refcount to fix the issue, or is it
>> nova's to refcount so that it doesn't call the release before all users are
>> done with it? I think solving it in the middle, in cinder's probably not
>> the right place to track it, but if its to be solved on nova's side, nova
>> needs to know when it needs to do it. But cinder might have to relay some
>> extra info from the backend.
>>
>> Either way, On the driver side, there probably needs to be a mechanism on
>> the driver to say it either can refcount properly so its multiattach
>> compatible (or that nova should refcount), or to default to not allowing
>> multiattach ever, so existing drivers don't break.
>>
>> Thanks,
>> Kevin
>> ________________________________________
>> From: Sean McGinnis [sean.mcginnis at gmx.com]
>> Sent: Wednesday, February 10, 2016 3:25 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Nova][Cinder] Multi-attach, determining
>> when to call os-brick's connector.disconnect_volume
>>
>> On Wed, Feb 10, 2016 at 11:16:28PM +0000, Fox, Kevin M wrote:
>> > I think part of the issue is whether to count or not is cinder driver
>> specific and only cinder knows if it should be done or not.
>> >
>> > But if cinder told nova that particular multiattach endpoints must be
>> refcounted, that might resolve the issue?
>> >
>> > Thanks,
>> > Kevin
>>
>> I this case (the point John and I were making at least) it doesn't
>> matter. Nothing is driver specific, so it wouldn't matter which backend
>> is being used.
>>
>> If a volume is needed, request it to be attached. When it is no longer
>> needed, tell Cinder to take it away. Simple as that.
>>
>>
>> __________________________________________________________________________
>> 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
>>
>> __________________________________________________________________________
>> 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
>>
>
> ​Hey Kevin,
>
> So I think what Sean M pointed out is still valid in your case.  It's not
> really that some drivers do bad things, the problem is actually the way
> attach/detach works in OpenStack as a whole.  The original design (which we
> haven't strayed very far from) was that you could only attach a single
> resource to a single compute node.  That was it, there was no concept of
> multi-attach etc.
>
> Now however folks want to introduce multi-attach, which means all of the
> old assumptions that the code was written on and designed around are kinda
> "bad assumptions" now.  It's true, as you pointed out however that there
> are some drivers that behave or deal with targets in a way that makes
> things complicated, but they're completely inline with the scsi standards
> and aren't doing anything *wrong*.
>
> The point Sean M and I were trying to make is that for the specific use
> case of a single volume being attached to a compute node, BUT being passed
> through to more than one Instance it might be worth looking at just
> ensuring that Compute Node doesn't call detach unless it's *done* with all
> of the Instances that it was passing that volume through to.
>
> You're absolutely right, there are some *weird* things that a couple of
> vendors do with targets in the case of like replication where they may
> actually create a new target and attach; those sorts of things are
> ABSOLUTELY Cinder's problem and Nova should not have to know anything about
> that as a consumer of the Target.
>
> My view is that maybe we should look at addressing the multiple use of a
> single target case in Nova, and then absolutely figure out how to make
> things work correctly on the Cinder side for all the different behaviors
> that may occur on the Cinder side from the various vendors.
>
> Make sense?
>
> John
>
> __________________________________________________________________________
> 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
>
>


-- 
*Avishay Traeger, PhD*
*System Architect*

Mobile: +972 54 447 1475
E-mail: avishay at stratoscale.com



Web <http://www.stratoscale.com/> | Blog <http://www.stratoscale.com/blog/>
 | Twitter <https://twitter.com/Stratoscale> | Google+
<https://plus.google.com/u/1/b/108421603458396133912/108421603458396133912/posts>
 | Linkedin <https://www.linkedin.com/company/stratoscale>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/b0f43da5/attachment.html>