On 09/07/15 at 09:27am, Ken'ichi Ohmichi wrote:
Hi Andrew,
2015-09-04 23:45 GMT+09:00 Andrew Laski <and...@lascii.com>:
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.
In short-term, yes. That is almost the same as "additionalProperties: True".
But in long-term, no. Each scheduler-hint parameter which is described
with JSON-Schema will be useful instead of "additionalProperties:
True" because API parameters will be exposed with JSON-Schema format
on JSON-Home or something.
If we allow customization of scheduler-hints like new filters,
out-of-tree filters without microversions, API users cannot know
available scheduler-hints parameter from microversions number.
That will be helpful for API users that nova can provide available
parameters with JSON-Home or something.
The issue that I still have is that I don't believe that scheduler hints
belong in the interopable cloud story, at least not any time soon. I
think scheduling is one place that different cloud providers can
distinguish themselves and I don't think there's anything wrong with
that. It's very coupled to the underlying infrastructure that runs the
cloud and I haven't yet seen the proper abstraction that can properly
reconcile the differences that happen there between different clouds, at
least beyond the simple level of host affinity. Now after saying that I
would love to find a solution that allows for a strict API around
scheduling while still providing flexibility to cloud providers. I
don't assume it can't be done, I just don't think we're at a place where
adding strictness adds any real value.
I would compare this to flavor extra specs. There are a lot of
proposals to do things with extra specs which we would not want to
introduce to Nova in that way. However there are clouds out there that
have out of tree code that relies on data in flavor extra specs. And
discussions that I've been involved in around that have focused on how
to introduce those concepts into Nova in a standard way that doesn't
rely on an unversioned key/value store like extra specs. The solution
hasn't been to introduce a schema on extra specs and lock them down so
they share meaning across clouds. It's been to acknowledge that extra
specs is a mess that doesn't provide what we want in a manageable way so
we should deprecate it's usage in favor of better methods. I think the
same applies to scheduler hints. Let's acknowledge that they're a mess
and rather than trying to impose order on them we should focus on other
improvements around scheduling. My big fear is still that we introduce
microversion 2.42 which adds scheduler hint foo which is now a permanent
part of the Nova API. And what contortions will we need to go through
to maintain that if we get to a point where the scheduler is no longer
in Nova or that hint for some reason no longer makes logical sense.
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
