[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