Thanks a for the information, I will propose a blueprint for the next cycle :)
On Wed, Dec 7, 2016 at 4:38 PM, Sylvain Bauza <sba...@redhat.com> wrote: > > > Le 07/12/2016 04:21, Zhenyu Zheng a écrit : > > Hi all, > > > > I want to ask a question about using scheduler-hints, could we add > > custom scheduler keys to work with our custom filters? Is it designed to > > allow vendors add own custom filters and keys? > > > > I tend to disagree with that approach from an interoperability > perspective as two clouds could behave very differently. > > That said, there is a long-standing problem about scheduler hints being > extensible with regards to our API input validation [1] and we basically > agreed on allowing to relax the constraints [2]. > > Long story short, you *can* technically do that for a custom filter but > please take care of the communication you make around that new hint to > your customers and make it clear that this hint is not interoperable. > > Also, I beg you to make sure that the hint name is self-explanatory and > enough distinct from the other hints we already have so that a confusion > could be minimal. > > > > Another question is, as we have now persistent scheduler-hints in > > request spec, is it possible to show the scheduler-hints either in > > server-show or a new API? Because vendors may be interested to have an > > idea on how this instance was built in the first place. > > > > Well, I'd say it would be an admin or owner information, but yeah that > could be worth to be exposed. > AFAIK, there is no current way to get that so a blueprint with a spec > describing the problem and the proposal (including an API microversion) > could be interesting to review. > > -Sylvain > > [1] http://lists.openstack.org/pipermail/openstack-dev/2015- > June/067996.html > > [2] > https://github.com/openstack/nova/blob/5cc5a841109b082395d9664edcfc11 > e31fb678fa/nova/api/openstack/compute/schemas/scheduler_hints.py#L67-L71 > > > Thanks. > > > > > > ____________________________________________________________ > ______________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: > unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev