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