On 05/29/2015 06:27 AM, John Garbutt wrote:
On 27 May 2015 at 23:36, Robert Collins <[email protected]> wrote:
On 26 May 2015 at 03:37, Chris Friesen <[email protected]> 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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
