[openstack-dev] [nova] Deprecating CONF.block_device_allocate_retries_interval

Andrew Laski andrew.laski at rackspace.com
Fri Aug 15 15:12:37 UTC 2014


On 08/08/2014 08:42 AM, Nikola Đipanov wrote:
> On 08/06/2014 07:54 PM, Jay Pipes wrote:
>> I bring this up on the mailing list because I think Liyi's patch offers
>> an interesting future direction to the way that we think about our retry
>> approach in Nova. Instead of having hard-coded or configurable interval
>> times, I think Liyi's approach of calculating the interval length based
>> on some input values is a good direction to take.
>>
> This indeed is a problem that we've seen bite us a number of times, and
> I tried to solve it by proposing [1] but didn't get to work on it
> further yet.
>
> Having said that - after thinking about it more, I was not sure I like
> my own approach in [1] on the grounds of it being too generic (and
> overly elaborate) for the particular problem it is solving.
>
> I was then thinking of something similar to what is proposed here, where
> we would have a waiting time that is a function of a value that we could
> query Cinder on. Allocation rate proposed here seems to fit this nicely,
> but in my mind we would have a way to query cinder about it instead of
> hardcoding it, however this can be done later and in cooperation with
> the Cinder team.

I like this direction a lot, because the allocation time depends on 
Cinder and its backend more than anything.  Excepting perhaps image 
transfer speeds.

>> 2) We should deprecate the CONF.block_device_allocate_retries_interval
>> option only, and keep the CONF.block_device_allocate_retries
>> configuration option as-is, changing the help text to read something
>> like "Max number of retries. We calculate the interval of the retry
>> based on the size of the volume."
>>
> I'd go with this as the number of retries can still be useful as a tool
> for easy workaround and troubleshooting, but I'd put a big disclaimer
> that it is mostly meant for debugging/workaround purposes.

I disagree a bit with having a knob purely for debugging/workaround.  I 
think this is a place where it's very useful to have the knob though.  
The figures in the review seem sound, but this is probably not a place 
where one size is going to fit all.  Until/unless we can get some 
coordination between Nova and Cinder on this I think having a knob that 
is intended to be used is the right way to go.

> N.
>
> [1] https://review.openstack.org/#/c/87546/
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list