<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, Sep 23, 2015 at 1:34 PM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.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="HOEnZb"><div class="h5"><br>
<br>
On 9/23/2015 2:15 PM, Matt Riedemann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On 9/23/2015 1:46 PM, Ivan Kolodyazhny wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Matt,<br>
<br>
In Liberty, we introduced allow_availability_zone_fallback [1] option in<br>
Cinder config as fix for bug [2]. If you set this option, Cinder will<br>
create volume in a default AZ instead of set volume into the error state<br>
<br>
[1]<br>
<a href="https://github.com/openstack/cinder/commit/b85d2812a8256ff82934d150dbc4909e041d8b31" rel="noreferrer" target="_blank">https://github.com/openstack/cinder/commit/b85d2812a8256ff82934d150dbc4909e041d8b31</a><br>
<br>
[2] <a href="https://bugs.launchpad.net/cinder/+bug/1489575" rel="noreferrer" target="_blank">https://bugs.launchpad.net/cinder/+bug/1489575</a><br>
<br>
Regards,<br>
Ivan Kolodyazhny<br>
<br>
On Wed, Sep 23, 2015 at 9:00 PM, Matt Riedemann<br>
<<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a> <mailto:<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>>> wrote:<br>
<br>
I came across bug 1496235 [1] today. In this case the user is<br>
booting an instance from a volume using source=image, so nova<br>
actually does the volume create call to the volume API. They are<br>
booting the instance into a valid nova availability zone, but that<br>
same AZ isn't defined in Cinder, so the volume create request fails<br>
(since nova passes the instance AZ to cinder [2]).<br>
<br>
I marked this as invalid given how the code works.<br>
<br>
I'm posting here since I'm wondering if there are alternatives worth<br>
pursuing. For example, nova could get the list of AZs from the<br>
volume API and if the nova AZ isn't in that list, don't provide it<br>
on the volume create request. That's essentially the same as first<br>
creating the volume outside of nova and not specifying an AZ, then<br>
when doing the boot from volume, provide the volume_id as the source.<br>
<br>
The question is, is it worth doing that? I'm not familiar enough<br>
with how availability zones are meant to work between nova and<br>
cinder so it's hard for me to have much of an opinion here.<br>
<br>
[1] <a href="https://bugs.launchpad.net/nova/+bug/1496235" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bug/1496235</a><br>
[2]<br>
<br>
<a href="https://github.com/openstack/nova/blob/master/nova/virt/block_device.py#L381-L383" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/master/nova/virt/block_device.py#L381-L383</a><br>
<br>
<br>
--<br>
<br>
Thanks,<br>
<br>
Matt Riedemann<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>
<br>
<<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://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>
<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>
</blockquote>
<br>
Sorry but that seems like a hack.<br>
<br>
I'm trying to figure out the relationship between AZs in nova and cinder<br>
and so far no one seems to really know. In the cinder IRC channel I was<br>
told there isn't one, which would mean we shouldn't even try creating<br>
the volume using the server instance AZ.<br>
<br>
Also, if there is no relationship, I was trying to figure out why there<br>
is the cinder.cross_az_attach config option. That was added in grizzly<br>
[1]. I was thinking maybe it was a legacy artifact from nova-volume,<br>
but that was dropped in grizzly.<br>
<br>
So is cinder.cross_az_attach even useful?<br>
<br>
[1] <a href="https://review.openstack.org/#/c/21672/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/21672/</a><br>
<br>
</blockquote>
<br></div></div>
The plot thickens.<br>
<br>
I was checking to see what change was made to start passing the server instance az on the volume create call during boot from volume, and that was [1] which was added in kilo to fix a bug where boot from volume into a nova az will fail if cinder.cross_az_attach=False and storage_availability_zone is set in cinder.conf.<br>
<br>
So I guess we can't just stop passing the instance az to the volume create call.<br>
<br>
But what I'd really like to know is how this is all used between cinder and nova, or was this all some work done as part of a larger effort that was never completed? Basically, can we deprecate the cinder.cross_az_attach config option in nova and start decoupling this code?<br>
<br>
[1] <a href="https://review.openstack.org/#/c/157041/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/157041/</a><div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann<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>
</div></div></blockquote></div><div class="gmail_default" style="font-family:monospace,monospace">To be honest this is probably my fault, AZ's were pulled in as part of the nova-volume migration to Cinder and just sort of died. Quite frankly I wasn't sure "what" to do with them but brought over the concept and the zones that existing in Nova-Volume. It's been an issue since day 1 of Cinder, and as you note there are little hacks here and there over the years to do different things.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I think your question about whether they should be there at all or not is a good one. We have had some interest from folks lately that want to couple Nova and Cinder AZ's (I'm really not sure of any details or use-cases here).</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">My opinion would be until somebody proposes a clear use case and need that actually works that we consider deprecating it. </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">While we're on the subject (kinda) I've never been a very fond of having Nova create the volume during boot process either; there's a number of things that go wrong here (timeouts almost guaranteed for a "real" image) and some things that are missing last I looked like type selection etc.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">We do have a proposal to talk about this at the Summit, so maybe we'll have a descent primer before we get there :)</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"><br></div><div class="gmail_default" style="font-family:monospace,monospace">John</div></div></div>