<div dir="ltr">VM group is a good feature to have. <div>What are the proposed different group policies? </div><div>Can we have group affinity as optional policy. I get a feeling it is must from the document.</div><div><br>

</div><div>Thanks,</div><div>-Ravi.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 10, 2013 at 9:26 AM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 05/07/2013 01:46 PM, Senhua Huang (senhuang) wrote:<br>
> Hi all,<br>
><br>
> At the summit a few weeks ago, we (Gary Kotton, Gilad Zlotkin, Alex<br>
> Glikson, I and a few other Nova developers) were talking about group<br>
> scheduling, cross-project scheduling and so on. As a first step towards<br>
> these long term goals, we have been working on an API extension to Nova<br>
> that achieves the following goals:<br>
><br>
</div>>   * to allow tenants to create a "group", which defines the desired<br>
<div class="im">>     relationship among all the members within this group<br>
</div>>   * to allow tenants to add VM instances to an existing group<br>
>   * to allow tenants to remove a VM instance from an existing group<br>
>   * to allow tenants to specify policies (e.g., anti-affinity,<br>
<div class="im">>     network-proximity, rack-aware) that apply to the group<br>
</div>>   * to allow tenants to view/list/describe a particular group<br>
>   * to allow tenants to remove a group<br>
<div class="im">><br>
><br>
> In essence, "group" defines the relationship among individual instances.<br>
> You can think of it as the hyper edge with properties in a hyper graph<br>
> in the most abstract manner. There are several benefits of introducing<br>
> this additional construct:<br>
><br>
</div>>   * it is more intuitive to use than padding various hints to every<br>
<div class="im">>     related instance creation call (now the relationship among these<br>
>     instances are handled by "group"<br>
</div>>   * it makes easier to add scheduling algorithms that attempt to place a<br>
<div class="im">>     set of VM instances to achieve failure resilience, redundancy,<br>
>     topology-wareness and so on.<br>
><br>
><br>
> Gary, Alex, and I have put together an initial design doc on the API and<br>
> how to use it for group scheduling:<br>
> <a href="https://docs.google.com/document/d/1QUThPfZh6EeOOz1Yhyvx-jFUYHQgvCw9yBAGDGc0y78/edit?usp=sharing" target="_blank">https://docs.google.com/document/d/1QUThPfZh6EeOOz1Yhyvx-jFUYHQgvCw9yBAGDGc0y78/edit?usp=sharing</a><br>


><br>
> A related blue print is also created for Nova:<br>
> <a href="https://blueprints.launchpad.net/nova/+spec/group-api-extension" target="_blank">https://blueprints.launchpad.net/nova/+spec/group-api-extension</a><br>
><br>
> We'd appreciate your feedback on the API and blue print and in<br>
> particularly whether there are interesting potential use cases that<br>
> can/cannot be supported by this API extension.<br>
<br>
</div>I just read over this proposal.  I don't have much to add.  I think this<br>
will be a nice feature.  Nice work, guys.<br>
<br>
Given the timing of development, we may want to consider adding this as<br>
a v3 API only extension.  Completion of the v3 API is currently targeted<br>
at the same milestone as this work (havana-2).<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Russell Bryant<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Ravi<br>
</div>