Open Stack

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.

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.

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