Open Stack

Alex, agree with your comments. I think we need to think of both 1.
and 2. as the eventual outcome and the destination. IF we decide to
improve upon scheduling/polices at the heat level, that should be a
very nice and independent endeavor and we can all learn from it. I
dont think we can design this all upfront.

IMO the simple enough road is to do
1. simple resource group extension and show how it can be used to
specify groups of resources - no matter what you do on top of this,
you will need to specify groups of resources (e.g. API proposal from
Yathi/Garyk/Mike/Me)
2. have policies which can be simple scheduler hints for now
3. have some notion of intelligent scheduling (a simple example is a
solver scheduler)
4. have some notion of fast state management (like Boris' proposal)

Ref:
[api] https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit
[overall] https://docs.google.com/document/d/1IiPI0sfaWb1bdYiMWzAAx0HYR6UqzOan_Utgml5W1HI/edit

debo

Mike: I agree with most of your ideas of extensions to
heat/policies/ordering/dependencies etc but I wish we could start with
a simple API from the nova side that will grow into a cross services
thing while you could start from the Heat side and then eventually
come to teh same midpoint. I somehow feel we are almost there wrt the
1st cut of the API \cite{api}.

On Wed, Oct 9, 2013 at 11:11 PM, Alex Glikson <GLIKSON at il.ibm.com> wrote:
> Thanks for the pointer -- was not able to attend that meeting,
> unfortunately. Couple of observations, based on what I've heard till now.
> 1. I think it is important not to restrict the discussion to Nova resources.
> So, I like the general direction in [1] to target a generic mechanism and
> API. However, once we start following that path, it becomes more challenging
> to figure out which component should manage those cross-resource constructs
> (Heat sounds like a reasonable candidate -- which seems consistent with the
> proposal at [2]), and what should be the API between it and the services
> deciding on the actual placement of individual resources (nova, cinder,
> neutron).
> 2. Moreover, we should take into account that we may need to take into
> consideration multiple sources of topology -- physical (maybe provided by
> Ironic, affecting availability -- hosts, racks, etc), virtual-compute
> (provided by Nova, affecting resource isolation -- mainly hosts),
> virtual-network (affecting connectivity and bandwidth/latency.. think of SDN
> policies enforcing routing and QoS almost orthogonally to physical
> topology), virtual-storage (affecting VM-to-volume connectivity and
> bandwidth/latency.. think of FC network implying topology different than the
> physical one and the IP network one).
>
> I wonder whether we will be able to come up with a simple-enough initial
> approach & implementation, which would not limit the ability to extend &
> customize it going forward to cover all the above.
>
> Regards,
> Alex
>
> [1]
> https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit
> [2] https://wiki.openstack.org/wiki/Heat/PolicyExtension
>
> ====================================================================================================
> Alex Glikson
> Manager, Cloud Operating System Technologies, IBM Haifa Research Lab
> http://w3.haifa.ibm.com/dept/stt/cloud_sys.html |
> http://www.research.ibm.com/haifa/dept/stt/cloud_sys.shtml
> Email: glikson at il.ibm.com | Phone: +972-4-8281085 | Mobile: +972-54-6466667
> | Fax: +972-4-8296112
>
>
>
>
> From:        Mike Spreitzer <mspreitz at us.ibm.com>
> To:        OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>,
> Date:        10/10/2013 07:59 AM
> Subject:        Re: [openstack-dev] [scheduler] APIs for Smart Resource
> Placement - Updated Instance Group Model and API extension model - WIP Draft
> ________________________________
>
>
>
> Yes, there is more than the northbound API to discuss.  Gary started us
> there in the Scheduler chat on Oct 1, when he broke the issues down like
> this:
>
> 11:12:22 AM garyk: 1. a user facing API
> 11:12:41 AM garyk: 2. understanding which resources need to be tracked
> 11:12:48 AM garyk: 3. backend implementation
>
> The full transcript is at
> http://eavesdrop.openstack.org/meetings/scheduling/2013/scheduling.2013-10-01-15.08.log.html
>
> Alex Glikson <GLIKSON at il.ibm.com> wrote on 10/09/2013 02:14:03 AM:
>>
>> Good summary. I would also add that in A1 the schedulers (e.g., in
>> Nova and Cinder) could talk to each other to coordinate. Besides
>> defining the policy, and the user-facing APIs, I think we should
>> also outline those cross-component APIs (need to think whether they
>> have to be user-visible, or can be admin).
>>
>> Regards,
>> Alex _______________________________________________
> 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
>



-- 
-Debo~