<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 1, 2016 at 3:48 PM, Murray, Paul (HP Cloud) <span dir="ltr"><<a href="mailto:pmurray@hpe.com" target="_blank">pmurray@hpe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
> -----Original Message-----<br>
> From: D'Angelo, Scott<br>
><br>
> Matt, changing Nova to store the connector info at volume attach time does<br>
> help. Where the gap will remain is after Nova evacuation or live migration,<br>
<br>
</span>This will happen with shelve as well I think. Volumes are not detached in shelve<br>
IIRC.<br>
<div><div class="h5"><br>
> when that info will need to be updated in Cinder. We need to change the<br>
> Cinder API to have some mechanism to allow this.<br>
> We'd also like Cinder to store the appropriate info to allow a force-detach for<br>
> the cases where Nova cannot make the call to Cinder.<br>
> Ongoing work for this and related issues is tracked and discussed here:<br>
> <a href="https://etherpad.openstack.org/p/cinder-nova-api-changes" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/cinder-nova-api-changes</a><br>
><br>
> Scott D'Angelo (scottda)<br>
> ________________________________________<br>
> From: Matt Riedemann [<a href="mailto:mriedem@linux.vnet.ibm.com">mriedem@linux.vnet.ibm.com</a>]<br>
> Sent: Monday, February 29, 2016 7:48 AM<br>
> To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
> Subject: Re: [openstack-dev] [nova][cinder] volumes stuck detaching<br>
> attaching and force detach<br>
><br>
> On 2/22/2016 4:08 PM, Walter A. Boring IV wrote:<br>
> > On 02/22/2016 11:24 AM, John Garbutt wrote:<br>
> >> Hi,<br>
> >><br>
> >> Just came up on IRC, when nova-compute gets killed half way through a<br>
> >> volume attach (i.e. no graceful shutdown), things get stuck in a bad<br>
> >> state, like volumes stuck in the attaching state.<br>
> >><br>
> >> This looks like a new addition to this conversation:<br>
> >> <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-</a><br>
> December/0826<br>
> >> 83.html<br>
> >><br>
> >> And brings us back to this discussion:<br>
> >> <a href="https://blueprints.launchpad.net/nova/+spec/add-force-detach-to-nova" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/nova/+spec/add-force-detach-to-nova</a><br>
> >><br>
> >> What if we move our attention towards automatically recovering from<br>
> >> the above issue? I am wondering if we can look at making our usually<br>
> >> recovery code deal with the above situation:<br>
> >><br>
> <a href="https://github.com/openstack/nova/blob/834b5a9e3a4f8c6ee2e3387845fc24" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/834b5a9e3a4f8c6ee2e3387845fc24</a><br>
> >> c79f4bf615/nova/compute/manager.py#L934<br>
> >><br>
> >><br>
> >> Did we get the Cinder APIs in place that enable the force-detach? I<br>
> >> think we did and it was this one?<br>
> >> <a href="https://blueprints.launchpad.net/python-cinderclient/+spec/nova-force" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/python-cinderclient/+spec/nova-force</a><br>
> >> -detach-needs-cinderclient-api<br>
> >><br>
> >><br>
> >> I think diablo_rojo might be able to help dig for any bugs we have<br>
> >> related to this. I just wanted to get this idea out there before I<br>
> >> head out.<br>
> >><br>
> >> Thanks,<br>
> >> John<br>
> >><br>
> >><br>
> __________________________________________________________<br>
> ___________<br>
> >> _____<br>
> >><br>
> >> OpenStack Development Mailing List (not for usage questions)<br>
> >> Unsubscribe:<br>
> >> <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>
> > The problem is a little more complicated.<br>
> ><br>
> > In order for cinder backends to be able to do a force detach<br>
> > correctly, the Cinder driver needs to have the correct 'connector'<br>
> > dictionary passed in to terminate_connection.  That connector<br>
> > dictionary is the collection of initiator side information which is gleaned<br>
> here:<br>
> > <a href="https://github.com/openstack/os-brick/blob/master/os_brick/initiator/c" rel="noreferrer" target="_blank">https://github.com/openstack/os-brick/blob/master/os_brick/initiator/c</a><br>
> > onnector.py#L99-L144<br>
> ><br>
> ><br>
> > The plan was to save that connector information in the Cinder<br>
> > volume_attachment table.  When a force detach is called, Cinder has<br>
> > the existing connector saved if Nova doesn't have it.  The problem was<br>
> > live migration.  When you migrate to the destination n-cpu host, the<br>
> > connector that Cinder had is now out of date.  There is no API in<br>
> > Cinder today to allow updating an existing attachment.<br>
> ><br>
> > So, the plan at the Mitaka summit was to add this new API, but it<br>
> > required microversions to land, which we still don't have in Cinder's<br>
> > API today.<br>
> ><br>
> ><br>
> > Walt<br>
> ><br>
> ><br>
> __________________________________________________________<br>
> ____________<br>
</div></div>> > ____ OpenStack Development Mailing List (not for usage questions)<br>
<span class="">> > Unsubscribe:<br>
> > <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>
> Regarding storing off the initial connector information from the attach, does<br>
> this [1] help bridge the gap? That adds the connector dict to the<br>
> connection_info dict that is serialized and stored in the nova<br>
> block_device_mappings table, and then in that patch is used to pass it to<br>
> terminate_connection in the case that the host has changed.<br>
><br>
> [1] <a href="https://review.openstack.org/#/c/266095/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/266095/</a><br>
><br>
> --<br>
><br>
> Thanks,<br>
><br>
> Matt Riedemann<br>
><br>
><br>
> __________________________________________________________<br>
> ________________<br>
</span><span class="">> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-<br>
> <a href="http://request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">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>
</span>> __________________________________________________________<br>
<span class="im">> ________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: OpenStack-dev-<br>
</span><div class=""><div class="h5">> <a href="http://request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">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">​I think Matt's patch is closer to where we need to be than some of the other paths that folks are on actually.  There's a lot of complexity that's being proposed in my opinion that might not be needed.  I could be wrong, but I've been looking at what got things sort of messy to begin with and it mostly revolves around diverging on what cinders initialize_connection and attach calls do.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I worked on a couple of things that hopefully might help:</div><div class="gmail_default" style="font-family:monospace,monospace">[1] is a simple add to the devref in cinder just to help new driver writers get a better idea of what the expectations are here.  I realize that there are a couple of drivers in Cinder that have already diverged here, but it's at least a guideline.  I also realize that the workflow may be a bit different for devices like Ceph.​</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">The other thing that I started (haven't spent the time fixing up the horrid unit tests because I wanted feedback on the proposal first) is this patch here: [2].  The idea for the first step is to clean up the attach code that we have now and actually use some of the tables that Cinder provides.  </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Particularly we have a volume_attachments table that could persist all of the connector info rather easily and more importantly return an attachment-id to the caller.  We're already passing this info in, but sadly we're just not *doing* much with it.  </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">The idea here is that the caller (Nova or otherwise) doesn't need to mess with all this tracking of references, connectors etc. Instead, it just uses the returned attachment-id and that's it.  Note that we ALREADY have all of the connector info etc during the initialize and then the additional info on the attach calls.  We just weren't *doing* anything with it.  Nova is done with a volume and wants to detach it... just call "terminate_connection" with the volume-id and the attachment-id it received during initialize_connection.  Cinder can/should figure out what to do if it's a multi-attached volume on the same node or whatever.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">This makes detach a much simpler endeavor I think, because now you just provide the attachment-id, Cinder looks it up in it's DB and it has all of the info from the connector etc.  I realize this would be a change in the API in the future, but adding the attachment ID is backward compatible and won't break any existing callers.  </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">So what about multi-attach?  I mentioned that earlier and that would be the next piece of follow on work on the Cinder side if this idea is viewed as worth pursuing, but would require we agree to go this route on the Nova side as well.  Currently there are some challenges with the current Cinder implementation of multi-attach but I think they're pretty easy to change around, and then we could get back to just using a unique attachment-id for every attach call and handle the business of sorting and tracking those things on the Cinder side.  Again, trying to keep things simple and non-obtrusive for the consumer while maintaining backward compatibility.  Honestly, I don't think that any consumer of Cinder (Nova) should have to know anything about all of these details.  It should just simply be "Hey... Cinder; I'm attaching this volume *here*".</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">This proposal covers the *special* drivers that can't reuse a Tgt IQN, or that work with things like Access-Groups.  More importantly it provides all of the Cinder drivers more flexibility to do things in their own driver code if they need to while persisting all of the various data that might be desired.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Anyway, I would really love to keep working on this if there's interest, but if folks feel the right direction is to build in shared logic between the two sides and pass connector objects with every call, that's fair enough.  I do worry about complexity in some of what's being discussed though.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">[1]: <a href="https://review.openstack.org/#/c/285471/">https://review.openstack.org/#/c/285471/</a></div><div class="gmail_default" style="font-family:monospace,monospace">[2]: <a href="https://review.openstack.org/#/c/284867/">https://review.openstack.org/#/c/284867/</a></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Thanks,</div><div class="gmail_default" style="font-family:monospace,monospace">John</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">PS</div><div class="gmail_default" style="font-family:monospace,monospace">I know, the devref doc isn't publishing, I've fixed that up and submitted a patch to get that addressed</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><br></div></div>