Open Stack

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).

-- 
Russell Bryant