Open Stack

2015-09-04 11:14 GMT+08:00 Ken'ichi Ohmichi <ken1ohmichi at gmail.com>:

> Hi Andrew,
>
> Sorry for this late response, I missed it.
>
> 2015-06-25 23:22 GMT+09:00 Andrew Laski <andrew at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/d10cb2fb/attachment.html>