On 09/04/15 at 06:54pm, Ken'ichi Ohmichi wrote:
2015-09-04 12:14 GMT+09: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].
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.
https://review.openstack.org/#/c/220440 is a prototype for the above idea.
I like the idea of providing strict API validation for the scheduler
hints if it accounts for out of tree extensions like this would do. I
do have a slight concern about how this works in a world where the
scheduler does eventually get an HTTP interface that Nova uses and the
code isn't necessarily accessible, but that can be worried about later.
This does mean that the scheduler hints are not controlled by
microversions though, since we don't have a mechanism for out of tree
extensions to signal their presence that way. And even if they could it
would still mean that identical microversions on different clouds
wouldn't offer the same hints. If we're accepting of that, which isn't
really any different than having "additionalProperties: True", then this
seems reasonable to me.
Thanks
Ken Ohmichi
__________________________________________________________________________
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
