<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2015-09-04 11:14 GMT+08:00 Ken'ichi Ohmichi <span dir="ltr"><<a href="mailto:ken1ohmichi@gmail.com" target="_blank">ken1ohmichi@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Andrew,<br>
<br>
Sorry for this late response, I missed it.<br>
<div><div class="h5"><br>
2015-06-25 23:22 GMT+09:00 Andrew Laski <<a href="mailto:andrew@lascii.com">andrew@lascii.com</a>>:<br>
> I have been growing concerned recently with some attempts to formalize<br>
> scheduler hints, both with API validation and Nova objects defining them,<br>
> and want to air those concerns and see if others agree or can help me see<br>
> why I shouldn't worry.<br>
><br>
> Starting with the API I think the strict input validation that's being done,<br>
> as seen in<br>
> <a href="http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da</a>,<br>
> is unnecessary, and potentially problematic.<br>
><br>
> One problem is that it doesn't indicate anything useful for a client.  The<br>
> schema indicates that there are hints available but can make no claim about<br>
> whether or not they're actually enabled.  So while a microversion bump would<br>
> typically indicate a new feature available to an end user, in the case of a<br>
> new scheduler hint a microversion bump really indicates nothing at all.  It<br>
> does ensure that if a scheduler hint is used that it's spelled properly and<br>
> the data type passed is correct, but that's primarily useful because there<br>
> is no feedback mechanism to indicate an invalid or unused scheduler hint.  I<br>
> think the API schema is a poor proxy for that deficiency.<br>
><br>
> Since the exposure of a hint means nothing as far as its usefulness, I don't<br>
> think we should be codifying them as part of our API schema at this time.<br>
> At some point I imagine we'll evolve a more useful API for passing<br>
> information to the scheduler as part of a request, and when that happens I<br>
> don't think needing to support a myriad of meaningless hints in older API<br>
> versions is going to be desirable.<br>
><br>
> Finally, at this time I'm not sure we should take the stance that only<br>
> in-tree scheduler hints are supported.  While I completely agree with the<br>
> desire to expose things in cross-cloud ways as we've done and are looking to<br>
> do with flavor and image properties I think scheduling is an area where we<br>
> want to allow some flexibility for deployers to write and expose scheduling<br>
> capabilities that meet their specific needs.  Over time I hope we will get<br>
> to a place where some standardization can happen, but I don't think locking<br>
> in the current scheduling hints is the way forward for that.  I would love<br>
> to hear from multi-cloud users here and get some input on whether that's<br>
> crazy and they are expecting benefits from validation on the current<br>
> scheduler hints.<br>
><br>
> Now, objects.  As part of the work to formalize the request spec sent to the<br>
> scheduler there's an effort to make a scheduler hints object.  This<br>
> formalizes them in the same way as the API with no benefit that I can see.<br>
> I won't duplicate my arguments above, but I feel the same way about the<br>
> objects as I do with the API.  I don't think needing to update and object<br>
> version every time a new hint is added is useful at this time, nor do I<br>
> think we should lock in the current in-tree hints.<br>
><br>
> In the end this boils down to my concern that the scheduling hints api is a<br>
> really horrible user experience and I don't want it to be solidified in the<br>
> API or objects yet.  I think we should re-examine how they're handled before<br>
> that happens.<br>
<br>
</div></div>Now we are discussing this on <a href="https://review.openstack.org/#/c/217727/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/217727/</a><br>
for allowing out-of-tree scheduler-hints.<br>
When we wrote API schema for scheduler-hints, it was difficult to know<br>
what are available API parameters for scheduler-hints.<br>
Current API schema exposes them and I guess that is useful for API users also.<br>
<br>
One idea is that: How about auto-extending scheduler-hint API schema<br>
based on loaded schedulers?<br>
Now API schemas of "create/update/resize/rebuild a server" APIs are<br>
auto-extended based on loaded extensions by using stevedore<br>
library[1].<br></blockquote><div><br></div><div>Em....we will deprecate the extension from our API. this sounds like add more extension mechanism.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I guess we can apply the same way for scheduler-hints also in long-term.<br>
Each scheduler needs to implement a method which returns available API<br>
parameter formats and nova-api tries to get them then extends<br>
scheduler-hints API schema with them.<br>
That means out-of-tree schedulers also will be available if they<br>
implement the method.<br>
# In short-term, I can see "blocking additionalProperties" validation<br>
disabled by the way.<br>
<br>
Thanks<br>
Ken Ohmichi<br>
<br>
---<br>
[1]: <a href="https://github.com/openstack/nova/blob/master/doc/source/api_plugins.rst#json-schema" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/master/doc/source/api_plugins.rst#json-schema</a><br>
<div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>