Open Stack

The topic is "Scheduler hints for VM life
cycle<http://junodesignsummit.sched.org/event/77801877aa42b595f14ae8b020cd1999#>".
Thanks.


2014-05-04 10:06 GMT+08:00 Qiming Teng <tengqim at linux.vnet.ibm.com>:

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



-- 
Thanks,

Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140504/df33be9a/attachment.html>