Open Stack

Hi Andrew,

Sorry for this late response, I missed it.

2015-06-25 23:22 GMT+09:00 Andrew Laski <andrew at lascii.com>:
> I have been growing concerned recently with some attempts to formalize
> scheduler hints, both with API validation and Nova objects defining them,
> and want to air those concerns and see if others agree or can help me see
> why I shouldn't worry.
>
> Starting with the API I think the strict input validation that's being done,
> as seen in
> http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da,
> is unnecessary, and potentially problematic.
>
> One problem is that it doesn't indicate anything useful for a client.  The
> schema indicates that there are hints available but can make no claim about
> whether or not they're actually enabled.  So while a microversion bump would
> typically indicate a new feature available to an end user, in the case of a
> new scheduler hint a microversion bump really indicates nothing at all.  It
> does ensure that if a scheduler hint is used that it's spelled properly and
> the data type passed is correct, but that's primarily useful because there
> is no feedback mechanism to indicate an invalid or unused scheduler hint.  I
> think the API schema is a poor proxy for that deficiency.
>
> Since the exposure of a hint means nothing as far as its usefulness, I don't
> think we should be codifying them as part of our API schema at this time.
> At some point I imagine we'll evolve a more useful API for passing
> information to the scheduler as part of a request, and when that happens I
> don't think needing to support a myriad of meaningless hints in older API
> versions is going to be desirable.
>
> Finally, at this time I'm not sure we should take the stance that only
> in-tree scheduler hints are supported.  While I completely agree with the
> desire to expose things in cross-cloud ways as we've done and are looking to
> do with flavor and image properties I think scheduling is an area where we
> want to allow some flexibility for deployers to write and expose scheduling
> capabilities that meet their specific needs.  Over time I hope we will get
> to a place where some standardization can happen, but I don't think locking
> in the current scheduling hints is the way forward for that.  I would love
> to hear from multi-cloud users here and get some input on whether that's
> crazy and they are expecting benefits from validation on the current
> scheduler hints.
>
> Now, objects.  As part of the work to formalize the request spec sent to the
> scheduler there's an effort to make a scheduler hints object.  This
> formalizes them in the same way as the API with no benefit that I can see.
> I won't duplicate my arguments above, but I feel the same way about the
> objects as I do with the API.  I don't think needing to update and object
> version every time a new hint is added is useful at this time, nor do I
> think we should lock in the current in-tree hints.
>
> In the end this boils down to my concern that the scheduling hints api is a
> really horrible user experience and I don't want it to be solidified in the
> API or objects yet.  I think we should re-examine how they're handled before
> that happens.

Now we are discussing this on https://review.openstack.org/#/c/217727/
for allowing out-of-tree scheduler-hints.
When we wrote API schema for scheduler-hints, it was difficult to know
what are available API parameters for scheduler-hints.
Current API schema exposes them and I guess that is useful for API users also.

One idea is that: How about auto-extending scheduler-hint API schema
based on loaded schedulers?
Now API schemas of "create/update/resize/rebuild a server" APIs are
auto-extended based on loaded extensions by using stevedore
library[1].
I guess we can apply the same way for scheduler-hints also in long-term.
Each scheduler needs to implement a method which returns available API
parameter formats and nova-api tries to get them then extends
scheduler-hints API schema with them.
That means out-of-tree schedulers also will be available if they
implement the method.
# In short-term, I can see "blocking additionalProperties" validation
disabled by the way.

Thanks
Ken Ohmichi

---
[1]: https://github.com/openstack/nova/blob/master/doc/source/api_plugins.rst#json-schema