Le 04/09/2015 12:18, Ken'ichi Ohmichi a écrit :
Hi Alex,
Thanks for your comment.
IMO, this idea is different from the extension we will remove.
That is modularity for the maintenance burden.
By this idea, we can put the corresponding schema in each filter.
While I think it could be a nice move to have stevedore-loaded filters
for the FilterScheduler due to many reasons, I actually wouldn't want to
delay more than needed the compatibility change for the API validation
relaxing the scheduler hints.
In order to have a smooth transition, I'd rather just provide a change
for using stevedore with the filters and weighters (even if the
weighters are not using the API), and then once implemented, then do the
necessary change on the API level like the one you proposed.
In the meantime, IMHO we should accept rather sooner than later (meaning
for Liberty) https://review.openstack.org/#/c/217727/
Thanks for that good idea, I like it,
-Sylvain
2015年9月4日(金) 19:04 Alex Xu <sou...@gmail.com
<mailto:sou...@gmail.com>>:
2015-09-04 11:14 GMT+08:00 Ken'ichi Ohmichi <ken1ohmi...@gmail.com
<mailto: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
<mailto: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].
Em....we will deprecate the extension from our API. this sounds
like add more extension mechanism.
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.
Thanks
Ken Ohmichi
---
[1]:
https://github.com/openstack/nova/blob/master/doc/source/api_plugins.rst#json-schema
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://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://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
__________________________________________________________________________
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
