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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
