[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