On Wed, Feb 10, 2016 at 3:59 PM, Sean McGinnis <sean.mcgin...@gmx.com> wrote:
> 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.van...@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. > > Well said , I agree > 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. > Ahh, well that's a very valid reason to take a different approach. > > > > > 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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev