On 06/25/2015 10:22 AM, Andrew Laski wrote: > 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.
I totally agree. If hints are to become an object, then need to be _real_ resources that can be listed, and that have structured metadata that has an API. Flavors are a great example of this. From an end user perspective, I can ask the cloud what flavors exist, those flavors tell me information that I can use to make a decision, and I can pass in a reference to those things. If I pass in an invalid flavor, I get a meaningful error message. > 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. As a multi-cloud user, I do not use scheduler hints because there is no API to discover that they exist, and also no shared sense of semantics. (I know a flavor that claims 8G of RAM will give me, you guessed it, 8G of ram) So I consider scheduler hints currently to be COMPLETE vendor lock-in and/or only things to be used by private cloud folks who are also admins of their clouds. I would not touch them with a 10 foot pole until such a time as there is an actual API for listing, describing and selecting them. I would suggest that if we make one of those, we should quickly formalize meanings of fields - so that cloud can have specific hints that seem like cloud content - but that the way I learn about them is the same, and if there are two hints that do the same thing I can expect them to look the same in two different clouds. > 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. I have no opinion on this. > 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. I agree. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
