[openstack-dev] [nova] I think nova behaves poorly when booting multiple instances
Andrew Laski
andrew at lascii.com
Mon Jun 1 13:26:33 UTC 2015
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:
>OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list