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 > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev