<div dir="ltr">The topic is "<span class=""><a href="http://junodesignsummit.sched.org/event/77801877aa42b595f14ae8b020cd1999#" class="" id="77801877aa42b595f14ae8b020cd1999">Scheduler hints for VM life cycle</a></span>". Thanks.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-04 10:06 GMT+08:00 Qiming Teng <span dir="ltr"><<a href="mailto:tengqim@linux.vnet.ibm.com" target="_blank">tengqim@linux.vnet.ibm.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Thu, May 01, 2014 at 08:49:11PM +0800, Jay Lau wrote:<br>
> Jay Pipes and all, I'm planning to merge this topic to<br>
> <a href="http://junodesignsummit.sched.org/event/77801877aa42b595f14ae8b020cd1999after" target="_blank">http://junodesignsummit.sched.org/event/77801877aa42b595f14ae8b020cd1999after</a><br>
> some discussion in this week's Gantt IRC meeting, hope it is OK.<br>
><br>
> Thanks!<br>
<br>
</div>The link above didn't work.  How about telling us the name of the topic?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> 2014-05-01 19:56 GMT+08:00 Day, Phil <<a href="mailto:philip.day@hp.com">philip.day@hp.com</a>>:<br>
><br>
> > > ><br>
> > > > In the original API there was a way to remove members from the group.<br>
> > > > This didn't make it into the code that was submitted.<br>
> > ><br>
> > > Well, it didn't make it in because it was broken. If you add an instance<br>
> > to a<br>
> > > group after it's running, a migration may need to take place in order to<br>
> > keep<br>
> > > the semantics of the group. That means that for a while the policy will<br>
> > be<br>
> > > being violated, and if we can't migrate the instance somewhere to<br>
> > satisfy the<br>
> > > policy then we need to either drop it back out, or be in violation.<br>
> > Either some<br>
> > > additional states (such as being queued for inclusion in a group, etc)<br>
> > may be<br>
> > > required, or some additional footnotes on what it means to be in a group<br>
> > > might have to be made.<br>
> > ><br>
> > > It was for the above reasons, IIRC, that we decided to leave that bit<br>
> > out since<br>
> > > the semantics and consequences clearly hadn't been fully thought-out.<br>
> > > Obviously they can be addressed, but I fear the result will be ... ugly.<br>
> > I think<br>
> > > there's a definite possibility that leaving out those dynamic functions<br>
> > will look<br>
> > > more desirable than an actual implementation.<br>
> > ><br>
> > If we look at a server group as a general contained or servers, that may<br>
> > have an attribute that expresses scheduling policy, then it doesn't seem to<br>
> > ugly to restrict the conditions on which an add is allowed to only those<br>
> > that don't break the (optional) policy.    Wouldn't even have to go to the<br>
> > scheduler to work this out.<br>
> ><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><div>Thanks,<br><br></div>Jay<br></div>
</div>