On 05/27/15 at 07:38pm, Chris Friesen wrote:
On 05/27/2015 05:09 PM, Fox, Kevin M wrote:
If the current behavior is broken, and the behavior is causing problems with
things like fixing quota's, should it just be deprecated and pushed off to
orchestration rather then change it?
Is this causing problems with quotas? The problem I brought up isn't
with quotas but rather with all the instances being set to an error
state when we could have actually booted up a bunch of them.
In any case, even if we wanted to deprecate it (and I think an
argument could be made for that) we still have to decide what the
"correct" behaviour should be for the API as it exists today. In my
view the current behaviour doesn't match what a reasonable person
would expect given the description of the "min count" and "max count"
parameters.
I'm +1 on fixing the behavior here. As many instances as can be booted
should be, despite part of the initial block failing. The only reason I
can think of for failing all of them is if you want to consider the
request as a single operation that can either fail or succeed. But that
would be better handled outside of Nova with some orchestration IMO.
But we should get some feedback from the EC2 API folks as to what kind
of contract it needs to provide and ways for them to achieve that.
I'm also in favor of deprecating these parameters, or moving this
functionality into a separate API if it must be kept for EC2. However
what these parameters give users, versus orchestrating outside of Nova,
is the ability to have the instances all scheduled as a single block.
Outside of it being a performance optimization I think there's minimal
value in this, but it's there and should be kept in mind since removing
it may affect certain use cases.
Chris
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
