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

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to