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