<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
The wiki page for this proposal:
<div><a href="https://wiki.openstack.org/wiki/GroupApiExtension">https://wiki.openstack.org/wiki/GroupApiExtension</a></div>
<div><br>
</div>
<div>It is almost a direct copy of the Google Doc. </div>
<div><br>
</div>
<div>Feel free to edit it.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Senhua</div>
<div><br>
<div>
<div>On May 7, 2013, at 10:46 AM, Senhua Huang (senhuang) <<a href="mailto:senhuang@cisco.com">senhuang@cisco.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Hi all,
<div><br>
</div>
<div>At the summit a few weeks ago, we (Gary Kotton, <span style="font-size: 15px; font-family: Arial; vertical-align: baseline; " id="docs-internal-guid-7f7fe7c4-7ffc-ecb9-2725-16e9783b35e1">Gilad Zlotkin,</span> Alex Glikson, I and a few other Nova developers)
were talking about group scheduling, cross-project scheduling and so on. As a first step towards these long term goals, we have been working on an API extension to Nova that achieves the following goals:</div>
<div>
<ul class="MailOutline">
<li>to allow tenants to create a "group", which defines the desired relationship among all the members within this group</li><li>to allow tenants to add VM instances to an existing group</li><li>to allow tenants to remove a VM instance from an existing group</li><li>to allow tenants to specify policies (e.g., anti-affinity, network-proximity, rack-aware) that apply to the group</li><li>to allow tenants to view/list/describe a particular group</li><li>to allow tenants to remove a group</li></ul>
</div>
<div><br>
</div>
<div>In essence, "group" defines the relationship among individual instances. You can think of it as the hyper edge with properties in a hyper graph in the most abstract manner. There are several benefits of introducing this additional construct:</div>
<div>
<ul class="MailOutline">
<li>it is more intuitive to use than padding various hints to every related instance creation call (now the relationship among these instances are handled by "group"</li><li>it makes easier to add scheduling algorithms that attempt to place a set of VM instances to achieve failure resilience, redundancy, topology-wareness and so on.</li></ul>
<div><br>
</div>
</div>
<div>Gary, Alex, and I have put together an initial design doc on the API and how to use it for group scheduling:</div>
<div><a href="https://docs.google.com/document/d/1QUThPfZh6EeOOz1Yhyvx-jFUYHQgvCw9yBAGDGc0y78/edit?usp=sharing">https://docs.google.com/document/d/1QUThPfZh6EeOOz1Yhyvx-jFUYHQgvCw9yBAGDGc0y78/edit?usp=sharing</a></div>
<div><br>
</div>
<div>A related blue print is also created for Nova:</div>
<div><a href="https://blueprints.launchpad.net/nova/+spec/group-api-extension">https://blueprints.launchpad.net/nova/+spec/group-api-extension</a></div>
<div><br>
</div>
<div>We'd appreciate your feedback on the API and blue print and in particularly whether there are interesting potential use cases that can/cannot be supported by this API extension.</div>
<div><br>
</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Senhua </div>
</div>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>
</blockquote>
</div>
<br>
</div>
</body>
</html>