[openstack-dev] [Nova][Cinder] Multi-attach, determining when to call os-brick's connector.disconnect_volume

Fox, Kevin M Kevin.Fox at pnnl.gov
Wed Feb 10 23:16:28 UTC 2016


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
________________________________________
From: Sean McGinnis [sean.mcginnis at gmx.com]
Sent: Wednesday, February 10, 2016 2:59 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 03:30:42PM -0700, John Griffith wrote:
> On Tue, Feb 9, 2016 at 3:23 PM, Ildikó Váncsa <ildiko.vancsa at ericsson.com>
> wrote:
>
> >
> ​This may still be in fact the easiest way to handle this.  The only other
> thing I am still somewhat torn on here is that maybe Nova should be doing
> ref-counting WRT shared connections and NOT send the detach in that
> scenario to begin with?
>
> In the case of unique targets per-attach we already just "work", but if you
> are using the same target/attachment on a compute node for multiple
> instances, then you probably should keep track of that on the users end and
> not remove it while in use.  That seems like the more "correct" way to deal
> with this, but ​maybe that's just me.  Keep in mind we could also do the
> same ref-counting on the Cinder side if we so choose.

This is where I've been pushing too. It seems odd to me that the storage
domain should need to track how the volume is being used by the
consumer. Whether it is attached to one instance, 100 instances, or the
host just likes to keep it around as a pet, from the storage perspective
I don't know why we should care.

Looking beyond Nova usage, does Cinder now need to start tracking
information about containers? Bare metal hosts? Apps that are associated
with LUNs. It just seems like concepts that the storage component
shouldn't need to know or care about.

I know there's some history here and it may not be as easy as that. But
just wanted to state my opinion that in an ideal world (which I
recognize we don't live in) this should not be Cinder's concern.

>
> We talked about this at mid-cycle with the Nova team and I proposed
> independent targets for each connection on Cinder's side.  We can still do
> that IMO but that doesn't seem to be a very popular idea.

John, I don't think folks are against this idea as a concept. I think
the problem is I don't believe all storage vendors can support exposing
new targets for the same volume for each attachment.

>
> My point here is just that it seems like there might be a way to fix this
> without breaking compatibility in the API.  Thoughts?

> __________________________________________________________________________
> 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


More information about the OpenStack-dev mailing list