Open Stack

On 09/07/15 at 09:27am, Ken'ichi Ohmichi wrote:
>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.

The issue that I still have is that I don't believe that scheduler hints 
belong in the interopable cloud story, at least not any time soon.  I 
think scheduling is one place that different cloud providers can 
distinguish themselves and I don't think there's anything wrong with 
that.  It's very coupled to the underlying infrastructure that runs the 
cloud and I haven't yet seen the proper abstraction that can properly 
reconcile the differences that happen there between different clouds, at 
least beyond the simple level of host affinity.  Now after saying that I 
would love to find a solution that allows for a strict API around 
scheduling while still providing flexibility to cloud providers.  I 
don't assume it can't be done, I just don't think we're at a place where 
adding strictness adds any real value.

I would compare this to flavor extra specs.  There are a lot of 
proposals to do things with extra specs which we would not want to 
introduce to Nova in that way.  However there are clouds out there that 
have out of tree code that relies on data in flavor extra specs.  And 
discussions that I've been involved in around that have focused on how 
to introduce those concepts into Nova in a standard way that doesn't 
rely on an unversioned key/value store like extra specs.  The solution 
hasn't been to introduce a schema on extra specs and lock them down so 
they share meaning across clouds.  It's been to acknowledge that extra 
specs is a mess that doesn't provide what we want in a manageable way so 
we should deprecate it's usage in favor of better methods.  I think the 
same applies to scheduler hints.  Let's acknowledge that they're a mess 
and rather than trying to impose order on them we should focus on other 
improvements around scheduling.  My big fear is still that we introduce 
microversion 2.42 which adds scheduler hint foo which is now a permanent 
part of the Nova API.  And what contortions will we need to go through 
to maintain that if we get to a point where the scheduler is no longer 
in Nova or that hint for some reason no longer makes logical sense.


>
>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