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.

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.


2014-08-12 7:01 GMT+08:00 Jay Pipes <>:

> On 08/11/2014 05:58 PM, Jay Lau wrote:
>> I think the metadata in server group is an important feature and it
>> might be used by
>> for-server-group
>> Actually, we are now doing an internal development for above bp and want
>> to contribute this back to community later. We are now setting hard/soft
>> flags in server group metadata to identify if the server group want
>> hard/soft affinity.
>> I prefer Dan's first suggestion, what do you think?
>> =====================
>> If we care to have this functionality, then I propose we change the
>> attribute on the object (we can handle this with versioning) and reflect
>> it as "metadata" in the API.
>> =====================
> -1
> 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.
> 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:
> org/msg23055.html
> Best,
> -jay
> _______________________________________________
> OpenStack-dev mailing list


OpenStack-dev mailing list

Reply via email to