Open Stack

2015-09-04 12:14 GMT+09:00 Ken'ichi Ohmichi <ken1ohmichi at gmail.com>:
> 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.

https://review.openstack.org/#/c/220440 is a prototype for the above idea.

Thanks
Ken Ohmichi