[openstack-dev] [nova] Deprecating CONF.block_device_allocate_retries_interval
mbooth at redhat.com
Fri Aug 15 15:43:53 UTC 2014
On 15/08/14 16:12, Andrew Laski wrote:
> 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  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  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.
FYI, this bug is admittedly only from code inspection, but I think many
interval config variables are currently broken in Nova:
If they've never been used, they're presumably of limited value.
>>  https://review.openstack.org/#/c/87546/
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
Red Hat Engineering, Virtualisation Team
Phone: +442070094448 (UK)
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
More information about the OpenStack-dev