On 04/25/2014 03:15 PM, Jay Pipes wrote:
There are myriad problems with the above user experience and
implementation. Let me explain them.
1. The user isn't creating a "server group" when they issue a nova
server-group-create call. They are creating a policy and calling it a
group. Cognitive dissonance results from this mismatch.
I actually don't think this is true. From my perspective they are
actually creating a group, and then when booting servers they can be
added into the group.
The group happens to have a policy, it is not only a policy.
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.
4. There's no way to manually add members to the server group
Isn't this the same as item 2?
5. The act of telling the scheduler to place instances near or away from
some other instances has been hidden behind the server group API, which
means that users doing a nova help boot will see a --group option that
doesn't make much sense, as it doesn't describe the scheduling policy
There are many things hidden away that affect server booting...metadata
matching between host aggregates and flavor extra specs, for instance.
As I understand it, originally the concept of "server groups" was more
broad. They supported multiple policies, arbitrary group metadata, etc.
The scheduler policy was only one of the things that could be
associated with a group. This is why the underlying database structure
is more complicated than necessary for the current set of supported
What we have currently is sort of a "dumbed-down" version but now that
we have the basic support we can start adding in additional
functionality as desired.
OpenStack-dev mailing list