Open Stack

Hi Alex,

Thanks for  your comment.
IMO, this idea is different from the extension we will remove.
That is modularity for the maintenance burden.
By this idea, we can put the corresponding schema in each filter.

2015年9月4日(金) 19:04 Alex Xu <soulxu at gmail.com>:

> 2015-09-04 11:14 GMT+08: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].
>>
>
> Em....we will deprecate the extension from our API. this sounds like add
> more extension mechanism.
>
>
>> 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
>>
> __________________________________________________________________________
>> 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
>>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/34f28fe5/attachment.html>