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: glik...@il.ibm.com | Phone: +972-4-8281085 | Mobile: +972-54-6466667 | Fax: +972-4-8296112 From: Mike Spreitzer <mspre...@us.ibm.com> To: OpenStack Development Mailing List <openstack-dev@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 <glik...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
