[openstack-dev] [nova] Deprecating CONF.block_device_allocate_retries_interval
Jay Pipes
jaypipes at gmail.com
Wed Aug 6 17:54:33 UTC 2014
Hi Stackers!
So, Liyi Meng has an interesting patch up for Nova:
https://review.openstack.org/#/c/104876
that changes the way that the interval and number of retries is
calculated for a piece of code that waits around for a block device
mapping to become active.
Namely, the patch discards the value of the following configuration
options *if the volume size is not 0* (which is a typical case):
* CONF.block_device_allocate_retries_interval
* CONF.block_device_allocate_retries
and in their place, instead uses a hard-coded 60 max number of retries
and calculates a more "appropriate" interval by looking at the size of
the volume to be created. The algorithm uses the sensible idea that it
will take longer to allocate larger volumes than smaller volumes, and
therefore the interval time for larger volumes should be longer than
smaller ones.
So... here's the question: since this code essentially makes the above
two configuration options obselete for the majority of cases (where
volume size is not 0), should we do one of the following?
1) We should just deprecate both the options, with a note in the option
help text that these options are not used when volume size is not 0, and
that the interval is calculated based on volume size
or
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 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.
Thoughts?
-jay
More information about the OpenStack-dev
mailing list