Open Stack

Le 04/09/2015 12:18, Ken'ichi Ohmichi a écrit :
>
> 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.
>
>

While I think it could be a nice move to have stevedore-loaded filters 
for the FilterScheduler due to many reasons, I actually wouldn't want to 
delay more than needed the compatibility change for the API validation 
relaxing the scheduler hints.

In order to have a smooth transition, I'd rather just provide a change 
for using stevedore with the filters and weighters (even if the 
weighters are not using the API), and then once implemented, then do the 
necessary change on the API level like the one you proposed.

In the meantime, IMHO we should accept rather sooner than later (meaning 
for Liberty) https://review.openstack.org/#/c/217727/

Thanks for that good idea, I like it,

-Sylvain


> 2015年9月4日(金) 19:04 Alex Xu <soulxu at gmail.com 
> <mailto:soulxu at gmail.com>>:
>
>     2015-09-04 11:14 GMT+08:00 Ken'ichi Ohmichi <ken1ohmichi at gmail.com
>     <mailto: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
>         <mailto: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://OpenStack-dev-request@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://OpenStack-dev-request@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/ba8e2d21/attachment.html>