[Openstack-operators] Potential deprecation of cinder.cross_az_attach option in nova

Matt Riedemann mriedem at linux.vnet.ibm.com
Thu Sep 24 15:46:15 UTC 2015



On 9/23/2015 6:27 PM, Sam Morrison wrote:
> We very much rely on this and I see this is already merged! Great another patch I have to manage locally.
>
> 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.
>
> 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.
>
> I will reply in the mailing list post on the dev channel but it seems it’s too late.
>
> Sam
>
>
>
>> On 24 Sep 2015, at 6:49 am, Matt Riedemann <mriedem at linux.vnet.ibm.com> wrote:
>>
>> I wanted to bring this to the attention of the operators mailing list in case someone is relying on the cinder.cross_az_attach.
>>
>> 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].
>>
>> 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.
>>
>> [1] http://lists.openstack.org/pipermail/openstack-dev/2015-September/075264.html
>> [2] https://review.openstack.org/#/c/226977/
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

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.

-- 

Thanks,

Matt Riedemann




More information about the OpenStack-operators mailing list