<div dir="ltr">We use cinder.cross_az_attach=False as a way of separating failure domains. Each AZ is effectively a set of racks with compute and storage in them, this way we keep the compute and storage close to each other and in the event of an issue in one AZ it won't affect the other (mostly).<div><br></div><div>In this scenario a user could attach a volume from AZ1 to a nova compute in AZ2. If AZ1 went down then the instance would be affected.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 24 September 2015 at 16:46, 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"><span class=""><br>
<br>
On 9/23/2015 6:27 PM, Sam Morrison wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We very much rely on this and I see this is already merged! Great another patch I have to manage locally.<br>
<br>
I don’t understand what the confusion is. We have multiple availability zones in nova and each zone has a corresponding cinder-volume service(s) in the same availability zone.<br>
<br>
We don’t want people attaching a volume from one zone to another as the network won’t allow that as the zones are in different network domains and different data centres.<br>
<br>
I will reply in the mailing list post on the dev channel but it seems it’s too late.<br>
<br>
Sam<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 24 Sep 2015, at 6:49 am, Matt Riedemann <<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>> wrote:<br>
<br>
I wanted to bring this to the attention of the operators mailing list in case someone is relying on the cinder.cross_az_attach.<br>
<br>
There is a -dev thread here [1] that started this discussion.  That led to a change proposed to deprecate the cinder.cross_az_attach option in nova [2].<br>
<br>
This is for deprecation in mitaka and removal in N.  If this affects you, please speak up in the mailing list or in the review.<br>
<br>
[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-September/075264.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-September/075264.html</a><br>
[2] <a href="https://review.openstack.org/#/c/226977/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/226977/</a><br>
<br>
--<br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</blockquote>
<br>
</blockquote>
<br></span>
The revert is approved.  Having done that, this is a mess of a feature, at least in the boot from volume case where source != volume.  The details on that are in the -dev thread but I'd appreciate operators that are using this to weigh in there on how they are handling the BFV case with cinder.cross_az_attach=False.  My main issue is the amount of API policy being defined in config options and when BFV fails to create the volume it's in the compute layer where we end up with a NoValidHost for the user.  I want to figure out how we can fail fast with a 400 response from nova API if we know the volume create is going to fail.<div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div></div></blockquote></div><br></div>