Open Stack

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 [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.

FYI, this bug is admittedly only from code inspection, but I think many
interval config variables are currently broken in Nova:

https://bugs.launchpad.net/nova/+bug/1354403

If they've never been used, they're presumably of limited value.

Matt

> 
>> 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
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490