Open Stack

Hi Michael, 

Not sure if I am getting your right. I think your proposal doesn't not perform well in reality. 

Firstly, it is difficult to guess a good time that fix all problems, except  you take "forever". Just take the volume creation in my bugfix as example (https://review.openstack.org/#/c/104876/). If a couple of large volumes are requested to create at the same time toward a fast storage backend, it would take a long time for each to create. It is quite normal to see it takes more than an hour to create a volume from a 60G image. That is why I proposal we need to "guess" a total timeout base on image size in the bugfix.  

Secondly, are you suggesting Eventlet sleep for "15 minute" then check the result of operation, without doing anything in between? IMHO, this would be very bad experience for end user! Because they ALWAYS have to wait for 15 minutes to move on regardless what operation they have issued. 

BR/Liyi 

 
________________________________________
From: mikalstill at gmail.com [mikalstill at gmail.com] on behalf of Michael Still [mikal at stillhq.com]
Sent: Wednesday, 06 August 2014 10:57 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Liyi Meng
Subject: Re: [openstack-dev] [nova] Deprecating CONF.block_device_allocate_retries_interval

Maybe we should change how we wait?

I get that we don't want to sit around forever, but perhaps we should
specify a total maximum time to wait instead of a number of iterations
of a loop? Something like "15 minutes should be long enough for
anyone!". Eventlet sleeps are also pretty cheap, so having a bigger
sleep time inside them just means that we overshoot more than we would
otherwise.

Michael

On Thu, Aug 7, 2014 at 3:54 AM, Jay Pipes <jaypipes at gmail.com> wrote:
> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Rackspace Australia