<div dir="ltr">Nice, good to know. Thanks all for the feedback. We will fix that in our drivers.<div><br></div><div>@Walter, so, in this case, if Cinder has the connector, it should not need to call the driver passing a None object right? <br></div><div><div> </div><div>Erlon</div></div></div><br><div class="gmail_quote"><div dir="ltr">Em qua, 18 de jul de 2018 às 12:56, Walter Boring <<a href="mailto:waboring@hemna.com">waboring@hemna.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The whole purpose of this test is to simulate the case where Nova doesn't know where the vm is anymore,<div>or may simply not exist, but we need to clean up the cinder side of things. That being said, with the new</div><div>attach API, the connector is being saved in the cinder database for each volume attachment. </div><div><br></div><div>Walt</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 18, 2018 at 5:02 AM, Gorka Eguileor <span dir="ltr"><<a href="mailto:geguileo@redhat.com" target="_blank">geguileo@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_8008596199008243872HOEnZb"><div class="m_8008596199008243872h5">On 17/07, Sean McGinnis wrote:<br>
> On Tue, Jul 17, 2018 at 04:06:29PM -0300, Erlon Cruz wrote:<br>
> > Hi Cinder and Nova folks,<br>
> ><br>
> > Working on some tests for our drivers, I stumbled upon this tempest test<br>
> > 'force_detach_volume'<br>
> > that is calling Cinder API passing a 'None' connector. At the time this was<br>
> > added several CIs<br>
> > went down, and people started discussing whether this (accepting/sending a<br>
> > None connector)<br>
> > would be the proper behavior for what is expected to a driver to do[1]. So,<br>
> > some of CIs started<br>
> > just skipping that test[2][3][4] and others implemented fixes that made the<br>
> > driver to disconnected<br>
> > the volume from all hosts if a None connector was received[5][6][7].<br>
><br>
> Right, it was determined the correct behavior for this was to disconnect the<br>
> volume from all hosts. The CIs that are skipping this test should stop doing so<br>
> (once their drivers are fixed of course).<br>
><br>
> ><br>
> > While implementing this fix seems to be straightforward, I feel that just<br>
> > removing the volume<br>
> > from all hosts is not the correct thing to do mainly considering that we<br>
> > can have multi-attach.<br>
> ><br>
><br>
> I don't think multiattach makes a difference here. Someone is forcibly<br>
> detaching the volume and not specifying an individual connection. So based on<br>
> that, Cinder should be removing any connections, whether that is to one or<br>
> several hosts.<br>
><br>
<br>
</div></div>Hi,<br>
<br>
I agree with Sean, drivers should remove all connections for the volume.<br>
<br>
Even without multiattach there are cases where you'll have multiple<br>
connections for the same volume, like in a Live Migration.<br>
<br>
It's also very useful when Nova and Cinder get out of sync and your<br>
volume has leftover connections. In this case if you try to delete the<br>
volume you get a "volume in use" error from some drivers.<br>
<br>
Cheers,<br>
Gorka.<br>
<div class="m_8008596199008243872HOEnZb"><div class="m_8008596199008243872h5"><br>
<br>
> > So, my questions are: What is the best way to fix this problem? Should<br>
> > Cinder API continue to<br>
> > accept detachments with None connectors? If, so, what would be the effects<br>
> > on other Nova<br>
> > attachments for the same volume? Is there any side effect if the volume is<br>
> > not multi-attached?<br>
> ><br>
> > Additionally to this thread here, I should bring this topic to tomorrow's<br>
> > Cinder's meeting,<br>
> > so please join if you have something to share.<br>
> ><br>
><br>
> +1 - good plan.<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>
__________________________________________________________________________<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>
</blockquote></div>