Open Stack

On 05/29/2015 06:27 AM, John Garbutt wrote:
> On 27 May 2015 at 23:36, Robert Collins <robertc at robertcollins.net> wrote:
>> On 26 May 2015 at 03:37, Chris Friesen <chris.friesen at windriver.com> wrote:

>>> Basically the problem is this:
>>>
>>> When booting up instances, nova allows the user to specify a "min count" and
>>> a "max count".  So logically, this request should be considered successful
>>> if at least "min count" instances can be booted.
>>>
>>> Currently, if the user has quota space for "max count" instances, then nova
>>> will try to create them all. If any of them can't be scheduled, then the
>>> creation of all of them will be aborted and they will all be put into an
>>> error state.

> The problem here is having a nice way to explicitly tell the users
> about what worked and what didn't. Currently the instance being in an
> error state because its the "good" way to tell the user that build
> failed. Deleting them doesn't have the same visibility, it can look
> like the just vanished.

Fair enough.  But we should only put the ones we couldn't schedule into an error 
state, not the ones that we could schedule (assuming we could schedule at least 
"min_count" instances).

> Having said all that, I am very tempted to say we should deprecate the
> "min_count" parameter in the API, keep the current behaviour for old
> version requests, and maybe even remove the "max_count" parameter. We
> could look to Heat to do a much better job of this kind of
> orchestration. This is very much in the spirit of:
> http://docs.openstack.org/developer/nova/devref/project_scope.html#no-more-orchestration

I'm totally in favour of doing a microversion bump and removing both "min_count" 
and "max_count" and saying if you want multiple instances then let something 
outside of nova handle it.

> Either which way, given the impact of the bug fix (i.e. it touches the
> API, and would probably need a micro version bump), I think it would
> be great to actually write up your proposal as a nova-spec (backlog or
> targeted at liberty, either way is cool). I think a spec review would
> be a great way to reach a good agreement on the best approach here.
>
>
> Chris, does that sounds like an approach that would work for you?

I'm happy to write up a spec to remove "min_count" and "max_count" and bump the 
microversion.

I don't think the bugfix for the current API version should have a microversion 
bump.  I think this is a case of "Fixing a bug so that a request which resulted 
in an error response before is now successful." from 
"http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html"

The user asked for between "min_count" and "max_count" instances.  If we can 
schedule at least "min_count" instances then we should do that and not give them 
nothing just because we couldn't schedule "max_count" instances.

Chris