Open Stack

Hi Sylvain,

2015-09-04 19:56 GMT+09:00 Sylvain Bauza <sbauza at redhat.com>:
>
>
> 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,

Thanks for your feedback :)

During the above idea implementation, I found a bug of API validation
for cell filter:
https://bugs.launchpad.net/nova/+bug/1492925

I feel now this way will exactly help us for maintaining the code.

Thanks
Ken Ohmichi

---

> 2015年9月4日(金) 19:04 Alex Xu <soulxu at gmail.com>:
>>
>> 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
>>
>> __________________________________________________________________________
>> 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
>
>
>
> __________________________________________________________________________
> 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
>
>
>
> __________________________________________________________________________
> 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
>