Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140411/0ce3a420/attachment.html>