Open Stack

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131010/1c70b3e4/attachment.html>