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. > >--Dan > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
