Open Stack

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