Open Stack

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.