2015-09-04 11:14 GMT+08:00 Ken'ichi Ohmichi <ken1ohmi...@gmail.com>: > Hi Andrew, > > Sorry for this late response, I missed it. > > 2015-06-25 23:22 GMT+09:00 Andrew Laski <and...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev