Hi Sylvain, 2015-09-04 19:56 GMT+09:00 Sylvain Bauza <[email protected]>: > > > 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,
Thanks for your feedback :) During the above idea implementation, I found a bug of API validation for cell filter: https://bugs.launchpad.net/nova/+bug/1492925 I feel now this way will exactly help us for maintaining the code. Thanks Ken Ohmichi --- > 2015年9月4日(金) 19:04 Alex Xu <[email protected]>: >> >> 2015-09-04 11:14 GMT+08:00 Ken'ichi Ohmichi <[email protected]>: >>> >>> Hi Andrew, >>> >>> Sorry for this late response, I missed it. >>> >>> 2015-06-25 23:22 GMT+09:00 Andrew Laski <[email protected]>: >>> > 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: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
