Open Stack

On 09/04/2015 02:31 PM, Sylvain Bauza wrote:
> 
> 
> Le 04/09/2015 14:57, Nikola Đipanov a écrit :
>> On 06/25/2015 04:50 PM, Monty Taylor wrote:
>>> On 06/25/2015 10:22 AM, Andrew Laski wrote:
>>>> 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.
>>> I totally agree.
>>>
>>> If hints are to become an object, then need to be _real_ resources that
>>> can be listed, and that have structured metadata that has an API.
>>> Flavors are a great example of this. From an end user perspective, I can
>>> ask the cloud what flavors exist, those flavors tell me information that
>>> I can use to make a decision, and I can pass in a reference to those
>>> things. If I pass in an invalid flavor, I get a meaningful error
>>> message.
>>>
>>>> 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.
>>> As a multi-cloud user, I do not use scheduler hints because there is no
>>> API to discover that they exist, and also no shared sense of semantics.
>>> (I know a flavor that claims 8G of RAM will give me, you guessed it, 8G
>>> of ram) So I consider scheduler hints currently to be COMPLETE vendor
>>> lock-in and/or only things to be used by private cloud folks who are
>>> also admins of their clouds.
>>>
>>> I would not touch them with a 10 foot pole until such a time as there is
>>> an actual API for listing, describing and selecting them.
>>>
>>> I would suggest that if we make one of those, we should quickly
>>> formalize meanings of fields - so that cloud can have specific hints
>>> that seem like cloud content - but that the way I learn about them is
>>> the same, and if there are two hints that do the same thing I can expect
>>> them to look the same in two different clouds.
>>>
>> So this kind of argumentation keeps confusing me TBH. Unless I am not
>> understanding some basic things about how Nova works, the above argument
>> cleanly applies to flavors as well. Flavor '42' is not going to be the
>> same thing across clouds, but that's not where this ends. Once you throw
>> in extra_specs, in particular related to PCI devices and NUMA/CPU
>> pinning features. There is really no discoverability there whatsoever
>> (*).
>>
>> What I am trying to get to is not whether this is right or wrong, but to
>> point out the fact that Flavors are simply not a good abstraction that
>> can have reasonable meaning "across cloud boundaries" (i.e. different
>> Nova deployments), at least the way they are implemented at the moment.
>> We should not pretend that they are, and try to demonize useful code
>> making use of them, but come up with a better abstraction that can have
>> reasonable meaning across different deployments.
>>
>> I think this is what Andrew was hinting at when he said that scheduling
>> is an area that cannot reasonably be standardized in this way.
>>
>> I recently spoke to John briefly about this and got the feeling that he
>> has similar views - but I'd encourage him to comment if he wishes to
>> do so.
>>
>> N.
>>
>> (*) For PCI devices, we can list aliases per host, but that's clearly an
>> admin API so not suitable for end user consumption really, and the alias
>> is an opaque string that is defined in nova.conf - has no meaning
>> outside a particular deployment really.
> 
> So, MHO on that is that hints and Flavors are children of a cloud. You
> can have the same name for two different boys, but unless you ask them
> who are their parents, you can't know who to ask.
> 
> Okay, the analogy is really bad. Let's stop it, and let me just provide
> some thoughts. While I'm really happy to have a consistent API for
> querying Flavors, we still need to ask the API to get the list of
> flavors and how they're set.
> 

You can't actually do this at all because extra specs are deployment
specific. Things that you expose have no meaning outside of the cloud
you are querying.


> Why couldn't it be the same for Scheduler hints ? Creating an API
> endpoint really clear about how to ask and what are the response body
> fields is IMHO then needed to help the users knowing what hints they can
> have and how to use them.
> 

Same as above.

> My .02 euros,
> -Sylvain
> 
> 
> 
>> __________________________________________________________________________
>>
>> 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