<div dir="ltr"><div><div>Thanks Jay Pipes! I see, but setting metadata for server group might be more flexible to handle all of the policy cases, such as hard affinity/anti-affinity, soft affinity/anti-affinity, topology affinity/anti-affinity etc, we may have more use cases in future related to server group metadata.<br>
<br></div><div>Regarding get rid of instance_group table, yes, it is a good idea for having "near", "not-near", "hard", and "soft", but it is a big change for current nova server group design, I'm not sure if we can have some clear conclusion in the coming one or two releases.<br>
</div><div><br></div><div>Thanks!<br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-08-12 7:01 GMT+08:00 Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 08/11/2014 05:58 PM, Jay Lau wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think the metadata in server group is an important feature and it<br>
might be used by<br>
<a href="https://blueprints.launchpad.net/nova/+spec/soft-affinity-for-server-group" target="_blank">https://blueprints.launchpad.<u></u>net/nova/+spec/soft-affinity-<u></u>for-server-group</a><br>
<br>
Actually, we are now doing an internal development for above bp and want<br>
to contribute this back to community later. We are now setting hard/soft<br>
flags in server group metadata to identify if the server group want<br>
hard/soft affinity.<br>
<br>
I prefer Dan's first suggestion, what do you think?<br>
=====================<br>
If we care to have this functionality, then I propose we change the<br>
attribute on the object (we can handle this with versioning) and reflect<br>
it as "metadata" in the API.<br>
=====================<br>
</blockquote>
<br></div>
-1<br>
<br>
If hard and soft is something that really needs to be supported, then this should be a field in the instance_groups table, not some JSON blob in a random metadata field.<br>
<br>
Better yet, get rid of the instance_groups table altogether and have "near", "not-near", "hard", and "soft" be launch modifiers similar to the instance type. IMO, there's really no need to store a named group at all, but that goes back to my original ML post about the server groups topic:<br>

<br>
<a href="https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg23055.html" target="_blank">https://www.mail-archive.com/<u></u>openstack-dev@lists.openstack.<u></u>org/msg23055.html</a><br>
<br>
Best,<br>
-jay<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><div>Thanks,<br><br></div>Jay<br></div>
</div>