[openstack-dev] [nova] Server Groups are not an optional element, bug or feature ?

Russell Bryant rbryant at redhat.com
Mon Apr 7 19:38:21 UTC 2014


On 04/07/2014 02:12 PM, Russell Bryant wrote:
> On 04/07/2014 01:43 PM, Day, Phil wrote:
>> Generally the scheduler’s capabilities that are exposed via hints can be
>> enabled or disabled in a Nova install by choosing the set of filters
>> that are configured.     However the server group feature doesn’t fit
>> that pattern – even if the affinity filter isn’t configured the
>> anti-affinity check on the server will still impose the anti-affinity
>> behavior via throwing the request back to the scheduler.
>>
>> I appreciate that you can always disable the server-groups API
>> extension, in which case users can’t create a group (and so the server
>> create will fail if one is specified), but that seems kind of at odds
>> with other type of scheduling that has to be specifically configured in
>> rather than out of a base system.    In particular having the API
>> extension in by default but the ServerGroup Affinity and AntiAffinity
>>  filters not in by default seems an odd combination (it kind of works,
>> but only by a retry from the host and that’s limited to a number of
>> retries).
>>
>> Given that the server group work isn’t complete yet (for example the
>> list of instances in a group isn’t tided up when an instance is deleted)
>> I feel a tad worried that the current default configuration exposed this
>> rather than keeping it as something that has to be explicitly enabled –
>> what do others think ?
> 
> I consider it a complete working feature.  It makes sense to enable the
> filters by default.  It's harmless when the API isn't used.  That was
> just an oversight.
> 
> The list of instances in a group through the API only shows non-deleted
> instances.
> 
> There are some implementation details that could be improved (the check
> on the server is the big one).
> 

https://bugs.launchpad.net/nova/+bug/1303983

-- 
Russell Bryant



More information about the OpenStack-dev mailing list