Open Stack

I think the metadata in server group is an important feature and it might
be used by
https://blueprints.launchpad.net/nova/+spec/soft-affinity-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.
=====================

Thanks!


2014-08-12 0:50 GMT+08:00 Sylvain Bauza <sbauza at redhat.com>:

>
> Le 11/08/2014 18:03, Gary Kotton a écrit :
>
>
>> On 8/11/14, 6:06 PM, "Dan Smith" <dms at danplanet.com> wrote:
>>
>>  As the person who -2'd the review, I'm thankful you raised this issue on
>>>> the ML, Jay. Much appreciated.
>>>>
>>> The "metadetails" term isn't being invented in this patch, of course. I
>>> originally complained about the difference when this was being added:
>>>
>>> https://review.openstack.org/#/c/109505/1/nova/api/
>>> openstack/compute/contr
>>> ib/server_groups.py,cm
>>>
>>> As best I can tell, the response in that patch set about why it's being
>>> translated is wrong (backwards). I expect that the API extension at the
>>> time called it "metadetails" and they decided to make the object the
>>> same and do the translation there.
>>>
>>>  >From what I can tell, the actual server_group API extension that made
>> it
>>
>>> into the tree never got the ability to set/change/etc the
>>> metadata/metadetails anyway, so there's no reason (AFAICT) to add it in
>>> wrongly.
>>>
>>> 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.
>>>
>>> However, I have to ask: do we really need another distinct metadata
>>> store attached to server_groups? If not, how about we just remove it
>>>
>> >from the database and the object, clean up the bit of residue that is
>>
>>> still in the API extension and be done with it?
>>>
>> The initial version of the feature did not make use of this. The reason
>> was that we chose for a very
>> Limited subset to be used, that is, affinity and anti affinity. Moving
>> forwards we would like to implement
>> A number of different policies with this. We can drop it at the moment due
>> to the fact that it is not used.
>>
>> I think that Yathi may be using this for the constrain scheduler. But I am
>> not 100% sure.
>>
>
>
> Unless I'm wrong, I can't see where this metadata is being used in the
> scheduler, either for filtering or for other reasons.
>
> So, please give us context why this is currently useful ?
>
> If this is something for the next future, I would love discussing it with
> regards to the current split.
>
>
> Thanks,
> -Sylvain
>
>
>  --Dan
>>>
>>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks,

Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140812/61b776f0/attachment.html>