Seems http://summit.openstack.org/cfp/details/262 can cover this? Thanks.
2014-04-25 5:09 GMT+08:00 Sylvain Bauza <[email protected]>: > > Le 24 avr. 2014 19:20, "Henrique Truta" <[email protected]> a > écrit : > > > > > Donald, > > > > By "selection", I think Jenny means identifying whether and which active > VM should be migrated, once the current Nova scheduler only deals with the > VM in the momment of its creation or with a specific user input. > > > > As Don said, we're beginning the process to spin-off the scheduler by > defining a line in the sand in between the sched and other Nova bits. > > That's the first step before the real fork which will lead to a separate > project standing by its own, Gantt. Having that said, the scope of Gantt is > currently still subject to discussion, which will happen during a Summit > design session. > > Regarding the need to have a dynamic scheduler acting also on > notifications and not only on boot requests, that could be seen either as > part to Gantt, or a separate service which would send request to Gantt for > selecting destinations. IMHO, with respect to the timeline, I would like to > see the finale endpoint going to Gantt, with a temporary Stackforge project > if necessary. > > Again, IMHO, this feature request deserves its own session proposal for > the Summit. As the deadline has passed for submissions, we need to know if > that has been proposed yet so we could add it as subject of interest for > Gantt in an etherpad. > > Thanks, > -Sylvain > > > > > 2014-04-24 12:08 GMT-03:00 Dugger, Donald D <[email protected]>: > > > >> Jenny- > >> > >> > >> > >> You should look at the `Propose Scheduler Library blueprint’: > >> > >> > >> > >> https://review.openstack.org/#/c/82133/9 > >> > >> > >> > >> This BP is to create a client library for making calls to the > scheduler. If you base your work upon this library then you shouldn’t need > to care about whether the Core Scheduler is the Nova integrated scheduler > or the Gantt separated scheduler, the library will call `a` scheduler as > appropriate. > >> > >> > >> > >> Having said that, I’m not sure I understand the distinction you are > seeing between `selection’ and `placement’. The current scheduler filters > all hosts based upon filters (the selection part) and then the weighting > function finds the best node to host the VM (the placement part). Seems to > me the current scheduler does both of those tasks. (We can argue the > effectiveness/efficiency of the current implementation but I think it’s > functionally complete.) > >> > >> > >> > >> Also, have you proposed a session at the Juno summit on your proposal > for dynamic scheduling, seems like it would be appropriate. > >> > >> > >> > >> -- > >> > >> Don Dugger > >> > >> "Censeo Toto nos in Kansa esse decisse." - D. Gale > >> > >> Ph: 303/443-3786 > >> > >> > >> > >> From: Jiangying (Jenny) [mailto:[email protected]] > >> Sent: Thursday, April 24, 2014 3:36 AM > >> To: OpenStack Development Mailing List (not for usage questions) > >> Subject: Re: [openstack-dev] [nova][ceilometer][gantt] Dynamic > scheduling > >> > >> > >> > >> Hi, > >> > >> We have checked that gantt now just made a synced up copy of the code > in nova. > >> > >> We still think dynamic scheduling will be a benefit of the nova > scheduler (or gantt later). The main difference between static and dynamic > scheduling is that static scheduling is a vm placement problem, while > dynamic scheduling deals with both vm selection and vm placement. > >> > >> > >> > >> Our scheduling mechanism consists of three parts: > >> > >> 1. Controller, which triggers the scheduling; > >> > >> 2. Data Collector, which collects the resource usage and topo for > scheduling; > >> > >> 3. Core Scheduler, which decides how to schedule the vms; > >> > >> > >> > >> We prefer to reuse the nova scheduler as the Core Scheduler, in order > to avoid the possible inconsistent between static scheduling and dynamic > scheduling. The vm selection function will be added into nova scheduler. > For Data Collector, we expect to get the performance data from ceilometer > and topo from nova. > >> > >> > >> > >> There is still one question that where the controller should be > implemented? > >> > >> We regard implementing the controller in nova scheduler as the first > choice. And we also consider extending ceilometer.(Ie. When ceilometer > discovers an overload host, an alarm can be reported and it can trigger a > vm evacuate.) > >> > >> > >> > >> Do you have any comments? > >> > >> > >> > >> Jenny > >> > >> > >> > >> 发件人: Henrique Truta [mailto:[email protected]] > >> 发送时间: 2014年4月12日 1:00 > >> 收件人: OpenStack Development Mailing List (not for usage questions) > >> 主题: Re: [openstack-dev] [nova] Dynamic scheduling > >> > >> > >> > >> Is there anyone currently working on Neat/Gantt projects? I'd like to > contribute to them, as well. > >> > >> > >> > >> 2014-04-11 11:37 GMT-03:00 Andrew Laski <[email protected]>: > >> > >> On 04/10/14 at 11:33pm, Oleg Gelbukh wrote: > >> > >> Andrew, > >> > >> Thank you for clarification! > >> > >> > >> On Thu, Apr 10, 2014 at 3:47 PM, Andrew Laski < > [email protected]>wrote: > >> > >> > >> > >> The scheduler as it currently exists is a placement engine. There is > >> sufficient complexity in the scheduler with just that responsibility so > I > >> would prefer to see anything that's making runtime decisions separated > out. > >> Perhaps it could just be another service within the scheduler project > once > >> it's broken out, but I think it will be beneficial to have a clear > >> distinction between placement decisions and runtime monitoring. > >> > >> > >> > >> Do you think that auto-scaling could be considered another facet of this > >> 'runtime monitoring' functionality? Now it is a combination of Heat and > >> Ceilometer. Does it worth moving to hypothetical runtime mobility > service > >> as well? > >> > >> > >> > >> Auto-scaling is certainly a facet of runtime monitoring. But > auto-scaling performs actions based on a set of user defined rules and is > very visible while the enhancements proposed below are intended to benefit > deployers and be very invisible to users. So the set of allowable actions > is very constrained compared to what auto-scaling can do. > >> In my opinion what's being proposed doesn't seem to fit cleanly into > any existing service, so perhaps it could start as a standalone entity. > Then once there's something that can be used and demoed a proper place > might suggest itself, or it might make sense to keep it separate. > >> > >> > >> > >> > >> -- > >> Best regards, > >> Oleg Gelbukh > >> > >> > >> > >> -- > >> Best regards, > >> Oleg Gelbukh > >> > >> > >> On Wed, Apr 9, 2014 at 7:47 PM, Jay Lau <[email protected]> wrote: > >> > >> @Oleg, Till now, I'm not sure the target of Gantt, is it for initial > >> > >> placement policy or run time policy or both, can you help clarify? > >> > >> @Henrique, not sure if you know IBM PRS (Platform Resource Scheduler) > >> [1], > >> we have finished the "dynamic scheduler" in our Icehouse version (PRS > >> 2.2), > >> it has exactly the same feature as your described, we are planning a > live > >> demo for this feature in Atlanta Summit. I'm also writing some document > >> for > >> run time policy which will cover more run time policies for OpenStack, > >> but > >> not finished yet. (My shame for the slow progress). The related > blueprint > >> is [2], you can also get some discussion from [3] > >> > >> [1] > >> http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype= > >> AN&subtype=CA&htmlfid=897/ENUS213-590&appname=USN > >> [2] > >> https://blueprints.launchpad.net/nova/+spec/resource- > >> optimization-service > >> [3] http://markmail.org/~jaylau/OpenStack-DRS > >> > >> Thanks. > >> > >> > >> 2014-04-09 23:21 GMT+08:00 Oleg Gelbukh <[email protected]>: > >> > >> Henrique, > >> > >> > >> You should check out Gantt project [1], it could be exactly the place to > >> implement such features. It is a generic cross-project Scheduler as a > >> Service forked from Nova recently. > >> > >> [1] https://github.com/openstack/gantt > >> > >> -- > >> Best regards, > >> Oleg Gelbukh > >> Mirantis Labs > >> > >> > >> On Wed, Apr 9, 2014 at 6:41 PM, Henrique Truta < > >> [email protected]> wrote: > >> > >> Hello, everyone! > >> > >> > >> I am currently a graduate student and member of a group of contributors > >> to OpenStack. We believe that a dynamic scheduler could improve the > >> efficiency of an OpenStack cloud, either by rebalancing nodes to > >> maximize > >> performance or to minimize the number of active hosts, in order to > >> minimize > >> energy costs. Therefore, we would like to propose a dynamic scheduling > >> mechanism to Nova. The main idea is using the Ceilometer information > >> (e.g. > >> RAM, CPU, disk usage) through the ceilometer-client and dinamically > >> decide > >> whether a instance should be live migrated. > >> > >> This might me done as a Nova periodic task, which will be executed > >> every > >> once in a given period or as a new independent project. In both cases, > >> the > >> current Nova scheduler will not be affected, since this new scheduler > >> will > >> be pluggable. We have done a search and found no such initiative in the > >> OpenStack BPs. Outside the community, we found only a recent IBM > >> announcement for a similiar feature in one of its cloud products. > >> > >> A possible flow is: In the new scheduler, we periodically make a call > >> to > >> Nova, get the instance list from a specific host and, for each > >> instance, we > >> make a call to the ceilometer-client (e.g. $ ceilometer statistics -m > >> cpu_util -q resource=$INSTANCE_ID) and then, according to some specific > >> parameters configured by the user, analyze the meters and do the proper > >> migrations. > >> > >> Do you have any comments or suggestions? > >> > >> -- > >> Ítalo Henrique Costa Truta > >> > >> > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> [email protected] > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> [email protected] > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> -- > >> Thanks, > >> > >> Jay > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> [email protected] > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> _______________________________________________ > >> > >> OpenStack-dev mailing list > >> [email protected] > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> [email protected] > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>> > >>> > >>> > >>> _______________________________________________ > >>> OpenStack-dev mailing list > >>> [email protected] > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> [email protected] > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> > >> -- > >> > >> -- > >> Ítalo Henrique Costa Truta > >> > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> [email protected] > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > > > > > -- > > -- > > Ítalo Henrique Costa Truta > > > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Thanks, Jay
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
