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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
