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
activity.

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 operations.

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.

Chris

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to