Open Stack

On 09/04/15 at 06:54pm, Ken'ichi Ohmichi wrote:
>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.

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.

>
>Thanks
>Ken Ohmichi
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev