Open Stack

On Mon, Apr 28, 2014 at 10:58:50AM -0600, Chris Friesen wrote:
> 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.

I tend to agree to this. Server groups today are just a starting point.
A server group can be used for different purposes like load-balancing, 
auto-scaling, high-availability or even a combination of them, just name
a few.  With that said, I would also like to see the policies separated 
from the group itself.  One or more policies can be associated with a
group (just like a 'floating-ip'), but the policies are managed
separately.
> >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.

To disallow "putting an apple into a basket of oranges", we will need to
come up with some admission control/validation.  It is complicated, but
doable, IMO.

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

Just like 'adding new members', 'removing members' can be done if
certain conditions are met.  We can safely assume the users do
understand what they are doing.  I mean, we can leave the high level
policy decisions to users, with nova only providing dumb mechanisms.

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

The confusion here is understandable, because we want to consider both
the policies and the mechanisms at the same time.  Maybe we can leave
the policies out of this discussion.

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