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