<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">Le 04/09/2015 12:18, Ken'ichi Ohmichi a
écrit :<br>
</div>
<blockquote
cite="mid:CAA393vhfetUH3PkJHkpcP9sf8vjzS+Tm-Fcp7O_D6mo3Q_S-xA@mail.gmail.com"
type="cite">
<p dir="ltr">Hi Alex,</p>
<p dir="ltr">Thanks for your comment.<br>
IMO, this idea is different from the extension we will remove.<br>
That is modularity for the maintenance burden.<br>
By this idea, we can put the corresponding schema in each
filter.<br>
</p>
<br>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
In the meantime, IMHO we should accept rather sooner than later
(meaning for Liberty) <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/217727/">https://review.openstack.org/#/c/217727/</a> <br>
<br>
Thanks for that good idea, I like it,<br>
<br>
-Sylvain<br>
<br>
<br>
<blockquote
cite="mid:CAA393vhfetUH3PkJHkpcP9sf8vjzS+Tm-Fcp7O_D6mo3Q_S-xA@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div dir="ltr">2015年9月4日(金) 19:04 Alex Xu <<a
moz-do-not-send="true" href="mailto:soulxu@gmail.com">soulxu@gmail.com</a>>:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">2015-09-04 11:14 GMT+08:00
Ken'ichi Ohmichi <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ken1ohmichi@gmail.com" target="_blank">ken1ohmichi@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi
Andrew,<br>
<br>
Sorry for this late response, I missed it.<br>
<div>
<div><br>
2015-06-25 23:22 GMT+09:00 Andrew Laski <<a
moz-do-not-send="true"
href="mailto:andrew@lascii.com" target="_blank">andrew@lascii.com</a>>:<br>
> I have been growing concerned recently with
some attempts to formalize<br>
> scheduler hints, both with API validation and
Nova objects defining them,<br>
> and want to air those concerns and see if
others agree or can help me see<br>
> why I shouldn't worry.<br>
><br>
> Starting with the API I think the strict
input validation that's being done,<br>
> as seen in<br>
> <a moz-do-not-send="true"
href="http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da"
rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da</a>,<br>
> is unnecessary, and potentially problematic.<br>
><br>
> One problem is that it doesn't indicate
anything useful for a client. The<br>
> schema indicates that there are hints
available but can make no claim about<br>
> whether or not they're actually enabled. So
while a microversion bump would<br>
> typically indicate a new feature available to
an end user, in the case of a<br>
> new scheduler hint a microversion bump really
indicates nothing at all. It<br>
> does ensure that if a scheduler hint is used
that it's spelled properly and<br>
> the data type passed is correct, but that's
primarily useful because there<br>
> is no feedback mechanism to indicate an
invalid or unused scheduler hint. I<br>
> think the API schema is a poor proxy for that
deficiency.<br>
><br>
> Since the exposure of a hint means nothing as
far as its usefulness, I don't<br>
> think we should be codifying them as part of
our API schema at this time.<br>
> At some point I imagine we'll evolve a more
useful API for passing<br>
> information to the scheduler as part of a
request, and when that happens I<br>
> don't think needing to support a myriad of
meaningless hints in older API<br>
> versions is going to be desirable.<br>
><br>
> Finally, at this time I'm not sure we should
take the stance that only<br>
> in-tree scheduler hints are supported. While
I completely agree with the<br>
> desire to expose things in cross-cloud ways
as we've done and are looking to<br>
> do with flavor and image properties I think
scheduling is an area where we<br>
> want to allow some flexibility for deployers
to write and expose scheduling<br>
> capabilities that meet their specific needs.
Over time I hope we will get<br>
> to a place where some standardization can
happen, but I don't think locking<br>
> in the current scheduling hints is the way
forward for that. I would love<br>
> to hear from multi-cloud users here and get
some input on whether that's<br>
> crazy and they are expecting benefits from
validation on the current<br>
> scheduler hints.<br>
><br>
> Now, objects. As part of the work to
formalize the request spec sent to the<br>
> scheduler there's an effort to make a
scheduler hints object. This<br>
> formalizes them in the same way as the API
with no benefit that I can see.<br>
> I won't duplicate my arguments above, but I
feel the same way about the<br>
> objects as I do with the API. I don't think
needing to update and object<br>
> version every time a new hint is added is
useful at this time, nor do I<br>
> think we should lock in the current in-tree
hints.<br>
><br>
> In the end this boils down to my concern that
the scheduling hints api is a<br>
> really horrible user experience and I don't
want it to be solidified in the<br>
> API or objects yet. I think we should
re-examine how they're handled before<br>
> that happens.<br>
<br>
</div>
</div>
Now we are discussing this on <a
moz-do-not-send="true"
href="https://review.openstack.org/#/c/217727/"
rel="noreferrer" target="_blank">https://review.openstack.org/#/c/217727/</a><br>
for allowing out-of-tree scheduler-hints.<br>
When we wrote API schema for scheduler-hints, it was
difficult to know<br>
what are available API parameters for scheduler-hints.<br>
Current API schema exposes them and I guess that is
useful for API users also.<br>
<br>
One idea is that: How about auto-extending
scheduler-hint API schema<br>
based on loaded schedulers?<br>
Now API schemas of "create/update/resize/rebuild a
server" APIs are<br>
auto-extended based on loaded extensions by using
stevedore<br>
library[1].<br>
</blockquote>
<div><br>
</div>
</div>
</div>
</div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>Em....we will deprecate the extension from our API.
this sounds like add more extension mechanism.</div>
<div> </div>
</div>
</div>
</div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
I guess we can apply the same way for scheduler-hints
also in long-term.<br>
Each scheduler needs to implement a method which
returns available API<br>
parameter formats and nova-api tries to get them then
extends<br>
scheduler-hints API schema with them.<br>
That means out-of-tree schedulers also will be
available if they<br>
implement the method.<br>
# In short-term, I can see "blocking
additionalProperties" validation<br>
disabled by the way.<br>
<br>
Thanks<br>
Ken Ohmichi<br>
<br>
---<br>
[1]: <a moz-do-not-send="true"
href="https://github.com/openstack/nova/blob/master/doc/source/api_plugins.rst#json-schema"
rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/master/doc/source/api_plugins.rst#json-schema</a><br>
</blockquote>
</div>
</div>
</div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
</div>
</div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>