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