Le 11/08/2014 18:03, Gary Kotton a écrit :
On 8/11/14, 6:06 PM, "Dan Smith" <d...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
