> > > > In the original API there was a way to remove members from the group. > > This didn't make it into the code that was submitted. > > Well, it didn't make it in because it was broken. If you add an instance to a > group after it's running, a migration may need to take place in order to keep > the semantics of the group. That means that for a while the policy will be > being violated, and if we can't migrate the instance somewhere to satisfy the > policy then we need to either drop it back out, or be in violation. Either > some > additional states (such as being queued for inclusion in a group, etc) may be > required, or some additional footnotes on what it means to be in a group > might have to be made. > > It was for the above reasons, IIRC, that we decided to leave that bit out > since > the semantics and consequences clearly hadn't been fully thought-out. > Obviously they can be addressed, but I fear the result will be ... ugly. I > think > there's a definite possibility that leaving out those dynamic functions will > look > more desirable than an actual implementation. > If we look at a server group as a general contained or servers, that may have an attribute that expresses scheduling policy, then it doesn't seem to ugly to restrict the conditions on which an add is allowed to only those that don't break the (optional) policy. Wouldn't even have to go to the scheduler to work this out.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
