Open Stack

2014-04-25 1:38 GMT+02:00 Jay Lau <jay.lau.513 at gmail.com>:

> Seems http://summit.openstack.org/cfp/details/262 can cover this? Thanks.
>
>
Well, that will depend on the number of sessions we could get. This #262
proposal was agreed to be merged with #140 if no enough slots.



>
> 2014-04-25 5:09 GMT+08:00 Sylvain Bauza <sylvain.bauza at gmail.com>:
>
>
>> Le 24 avr. 2014 19:20, "Henrique Truta" <henriquecostatruta at gmail.com> 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 <donald.d.dugger at intel.com
>> >:
>> >
>> >> 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:jenny.jiangying at huawei.com]
>> >> 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:henriquecostatruta at gmail.com]
>> >> 发送时间: 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 <andrew.laski at rackspace.com>:
>> >>
>> >> 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 <
>> andrew.laski at rackspace.com>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 <jay.lau.513 at gmail.com> 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 <ogelbukh at mirantis.com>:
>> >>
>> >> 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 <
>> >> henriquecostatruta at gmail.com> 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
>> >> OpenStack-dev at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >>
>> >> --
>> >> Thanks,
>> >>
>> >> Jay
>> >>
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >>  _______________________________________________
>> >>
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> OpenStack-dev mailing list
>> >>> OpenStack-dev at lists.openstack.org
>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> --
>> >> Ítalo Henrique Costa Truta
>> >>
>> >>
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >
>> >
>> >
>> > --
>> > --
>> > Ítalo Henrique Costa Truta
>> >
>> >
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Thanks,
>
> Jay
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140425/8b42c68a/attachment.html>