Open Stack

On 08/15/2014 11:43 AM, Matthew Booth wrote:
> 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.

Fair point.  Though it's likely they'll be fixed as soon as someone 
starts tuning them and finds them broken.  And it'll be easier to fix 
them than to remove them and add them in later.  Which is not to say 
that all of them are useful.

But the two values in question here are ones I've been tuning recently 
and know that they work.

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