[openstack-dev] Scheduler hints, API and Objects
Ken'ichi Ohmichi
ken1ohmichi at gmail.com
Mon Sep 7 00:27:09 UTC 2015
Hi Andrew,
2015-09-04 23:45 GMT+09:00 Andrew Laski <andrew at lascii.com>:
>>>
>>> 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.
>>
>>
>> https://review.openstack.org/#/c/220440 is a prototype for the above idea.
>
>
> I like the idea of providing strict API validation for the scheduler hints
> if it accounts for out of tree extensions like this would do. I do have a
> slight concern about how this works in a world where the scheduler does
> eventually get an HTTP interface that Nova uses and the code isn't
> necessarily accessible, but that can be worried about later.
>
> This does mean that the scheduler hints are not controlled by microversions
> though, since we don't have a mechanism for out of tree extensions to signal
> their presence that way. And even if they could it would still mean that
> identical microversions on different clouds wouldn't offer the same hints.
> If we're accepting of that, which isn't really any different than having
> "additionalProperties: True", then this seems reasonable to me.
In short-term, yes. That is almost the same as "additionalProperties: True".
But in long-term, no. Each scheduler-hint parameter which is described
with JSON-Schema will be useful instead of "additionalProperties:
True" because API parameters will be exposed with JSON-Schema format
on JSON-Home or something.
If we allow customization of scheduler-hints like new filters,
out-of-tree filters without microversions, API users cannot know
available scheduler-hints parameter from microversions number.
That will be helpful for API users that nova can provide available
parameters with JSON-Home or something.
Thanks
Ken Ohmichi
More information about the OpenStack-dev
mailing list