<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 02/12/2016 04:35 PM, John Griffith
wrote:<br>
</div>
<blockquote
cite="mid:CAPWkaSXr8jUDWgmaJg-XBucG4soersALujZtz5nHdHbygLMC3w@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div class="gmail_default"
style="font-family:monospace,monospace"><br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Feb 11, 2016 at 10:31 AM,
Walter A. Boring IV <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:walter.boring@hpe.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:walter.boring@hpe.com">walter.boring@hpe.com</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">There
seems to be a few discussions going on here wrt to
detaches. One is what to do on the Nova side with
calling os-brick's disconnect_volume, and also when to or
not to call Cinder's terminate_connection and detach.<br>
<br>
My original post was simply to discuss a mechanism to try
and figure out the first problem. When should nova call
brick to remove<br>
the local volume, prior to calling Cinder to do something.
<div class="gmail_default"
style="font-family:monospace,monospace;display:inline"></div>
</blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Nova needs to know if it's safe to call disconnect_volume
or not. Cinder already tracks each attachment, and it can
return the connection_info for each attachment with a call
to initialize_connection. If 2 of those connection_info
dicts are the same, it's a shared volume/target. Don't
call disconnect_volume if there are any more of those
left.<br>
<br>
On the Cinder side of things, if terminate_connection,
detach is called, the volume manager can find the list of
attachments for a volume, and compare that to the
attachments on a host. The problem is, Cinder doesn't
track the host along with the instance_uuid in the
attachments table. I plan on allowing that as an API
change after microversions lands, so we know how many
times a volume is attached/used on a particular host. The
driver can decide what to do with it at
terminate_connection, detach time. This helps account
for<br>
the differences in each of the Cinder backends, which we
will never get all aligned to the same model. Each
array/backend handles attachments different and only the
driver knows if it's safe to remove the target or not,
depending on how many attachments/usages it has<br>
on the host itself. This is the same thing as a
reference counter, which we don't need, because we have
the count in the attachments table, once we allow setting
the host and the instance_uuid at the same time.<br>
<br>
</blockquote>
<div>
<div class="gmail_default"
style="font-family:monospace,monospace;display:inline">
Not trying to drag this out or be difficult I promise.
But, this seems like it is in fact the same problem, and
I'm not exactly following; if you store the info on the
compute side during the attach phase, why would you
need/want to then create a split brain scenario and have
Cinder do any sort of tracking on the detach side of
things?</div>
</div>
<div>
<div class="gmail_default"
style="font-family:monospace,monospace;display:inline"><br>
</div>
</div>
<div>
<div class="gmail_default"
style="font-family:monospace,monospace;display:inline">Like
the earlier posts said, just don't call
terminate_connection if you don't want to really
terminate the connection? I'm sorry, I'm just not
following the logic of why Cinder should track this and
interfere with things? It's supposed to be providing a
service to consumers and "do what it's told" even if
it's told to do the wrong thing.</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
The only reason to store the connector information on the cinder
attachments side is in the few use cases when there is no way to get
that connector any more. Such as the case for nova evacuate, and
force detach where nova has no information about where the original
attachment was, because the instance is gone. Cinder backends
still need the connector at terminate_connection time, to find the
right exports/targets to remove. <br>
<br>
Walt<br>
</body>
</html>