<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 10, 2016 at 5:12 PM, Fox, Kevin M <span dir="ltr"><<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<span class=""><br>
Thanks,<br>
Kevin<br>
________________________________________<br>
From: Sean McGinnis [<a href="mailto:sean.mcginnis@gmx.com">sean.mcginnis@gmx.com</a>]<br>
</span>Sent: Wednesday, February 10, 2016 3:25 PM<br>
<span class="im HOEnZb">To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: Re: [openstack-dev] [Nova][Cinder] Multi-attach, determining when to call os-brick's connector.disconnect_volume<br>
<br>
</span><div class="HOEnZb"><div class="h5">On Wed, Feb 10, 2016 at 11:16:28PM +0000, Fox, Kevin M wrote:<br>
> 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.<br>
><br>
> But if cinder told nova that particular multiattach endpoints must be refcounted, that might resolve the issue?<br>
><br>
> Thanks,<br>
> Kevin<br>
<br>
I this case (the point John and I were making at least) it doesn't<br>
matter. Nothing is driver specific, so it wouldn't matter which backend<br>
is being used.<br>
<br>
If a volume is needed, request it to be attached. When it is no longer<br>
needed, tell Cinder to take it away. Simple as that.<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra"><div class="gmail_default" style="font-family:monospace,monospace">Hey Kevin,</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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*.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Make sense?</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">John</div></div></div>