Open Stack

On Thu, May 01, 2014 at 08:49:11PM +0800, Jay Lau wrote:
> Jay Pipes and all, I'm planning to merge this topic to
> http://junodesignsummit.sched.org/event/77801877aa42b595f14ae8b020cd1999after
> some discussion in this week's Gantt IRC meeting, hope it is OK.
> 
> Thanks!

The link above didn't work.  How about telling us the name of the topic?


> 2014-05-01 19:56 GMT+08:00 Day, Phil <philip.day at hp.com>:
> 
> > > >
> > > > 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.
> > >
> > > 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.
> > >
> > If we look at a server group as a general contained or servers, that may
> > have an attribute that expresses scheduling policy, then it doesn't seem to
> > ugly to restrict the conditions on which an add is allowed to only those
> > that don't break the (optional) policy.    Wouldn't even have to go to the
> > scheduler to work this out.
> >