[openstack-dev] [nova] Proposal: remove the server groups feature
Chris Friesen
chris.friesen at windriver.com
Mon Apr 28 18:13:45 UTC 2014
On 04/28/2014 11:22 AM, Dan Smith wrote:
>>> 2. There's no way to add an existing server to this "group".
>>
>> In the original API there was a way to add existing servers to the
>> group. This didn't make it into the code that was submitted. It is
>> however supported by the instance group db API in nova.
>>
>>> 3. There's no way to remove members from the group
>>
>> 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.
I think your comment actually applies to adding existing instances to a
group. There's no good reason not to allow removing instances from a group.
As for the case of addition, we could start with something simple...if
adding an instance to a group would violate the group scheduling policy,
then raise an exception.
> 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.
Your idea of "pending group membership" doesn't sound too ugly.
That said, I would expect "adding existing instances to a group" to be
something that would be done under fairly well-controlled circumstances.
In that case I think it would be reasonable to push the work of
managing any migrations onto whoever is trying to create a group from
existing instances.
Chris
More information about the OpenStack-dev
mailing list