<font size=2 face="sans-serif">Thanks for the pointer -- was not able
to attend that meeting, unfortunately. Couple of observations, based on
what I've heard till now.</font>
<br><font size=2 face="sans-serif">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). </font>
<br><font size=2 face="sans-serif">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).</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br><font size=2 face="sans-serif">Alex</font>
<br>
<br><font size=2 face="sans-serif">[1] </font><a href="https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit"><font size=3 color=blue><u>https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit</u></font></a><font size=3>
</font><font size=2 face="sans-serif"><br>
[2] </font><a href=https://wiki.openstack.org/wiki/Heat/PolicyExtension><font size=3 color=blue><u>https://wiki.openstack.org/wiki/Heat/PolicyExtension</u></font></a><font size=3>
</font>
<br><font size=2 face="sans-serif"><br>
====================================================================================================<br>
Alex Glikson<br>
Manager, Cloud Operating System Technologies, IBM Haifa Research Lab<br>
</font><a href=http://w3.haifa.ibm.com/dept/stt/cloud_sys.html><font size=2 face="sans-serif">http://w3.haifa.ibm.com/dept/stt/cloud_sys.html</font></a><font size=2 face="sans-serif">
| </font><a href=http://www.research.ibm.com/haifa/dept/stt/cloud_sys.shtml><font size=2 face="sans-serif">http://www.research.ibm.com/haifa/dept/stt/cloud_sys.shtml</font></a><font size=2 face="sans-serif">
<br>
Email: glikson@il.ibm.com | Phone: +972-4-8281085 | Mobile: +972-54-6466667
| Fax: +972-4-8296112<br>
</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Mike Spreitzer <mspreitz@us.ibm.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">OpenStack Development
Mailing List <openstack-dev@lists.openstack.org>, </font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">10/10/2013 07:59 AM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [openstack-dev]
[scheduler] APIs for Smart Resource Placement - Updated Instance Group
Model and API extension model - WIP Draft</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=2 face="sans-serif">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:</font><font size=3> <br>
</font><font size=3 color=#808080><br>
11:12:22 AM</font><font size=3> </font><font size=3 color=#000080>garyk:</font><font size=3>
1. a user facing API </font><font size=3 color=#808080><br>
11:12:41 AM</font><font size=3> </font><font size=3 color=#000080>garyk:</font><font size=3>
2. understanding which resources need to be tracked </font><font size=3 color=#808080><br>
11:12:48 AM</font><font size=3> </font><font size=3 color=#000080>garyk:</font><font size=3>
3. backend implementation <br>
</font><font size=2 face="sans-serif"><br>
The full transcript is at </font><a href="http://eavesdrop.openstack.org/meetings/scheduling/2013/scheduling.2013-10-01-15.08.log.html"><font size=2 color=blue face="sans-serif"><u>http://eavesdrop.openstack.org/meetings/scheduling/2013/scheduling.2013-10-01-15.08.log.html</u></font></a><font size=3>
<br>
</font><tt><font size=2><br>
Alex Glikson <GLIKSON@il.ibm.com> wrote on 10/09/2013 02:14:03 AM:<br>
> <br>
> Good summary. I would also add that in A1 the schedulers (e.g., in
<br>
> Nova and Cinder) could talk to each other to coordinate. Besides <br>
> defining the policy, and the user-facing APIs, I think we should <br>
> also outline those cross-component APIs (need to think whether they
<br>
> have to be user-visible, or can be admin). <br>
> <br>
> Regards, <br>
> Alex _______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br>