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