Open Stack

On 08/02/2016 08:19 AM, Alex Xu wrote:
> Chris have a thought about using ResourceClass to describe Capabilities
> with an infinite inventory. In the beginning we brain storming the idea
> of Tags, Tan Lin have same thought, but we say no very quickly, due to
> the ResourceClass is really about Quantitative stuff. But Chris give
> very good point about simplify the ResourceProvider model and the API.
>
> After rethinking about those idea, I like simplify the ResourceProvider
> model and the API. But I think the direction is opposite. ResourceClass
> with infinite inventory is really hacky. The Placement API is simple,
> but the usage of those API isn't simple for user, they need create a
> ResourceClass, then create an infinite inventory. And ResourceClass
> isn't managable like Tags, look at the Tags API, there are many query
> parameter.
>
> But look at the ResourceClass and ResourceProviderTags, they are totally
> same, two columns: one is integer id, another one is string.
> ResourceClass is just for naming the quantitative stuff. So what we need
> is thing used to 'naming'. ResourceProviderTags is higher abstract, Tags
> is generic thing to name something, we totally can use Tag instead of
> ResourceClass. So user can create inventory with tags, also user can
> create ResourceProvider with tags.

No, this sounds like actually way more complexity than is needed and 
will make the schema less explicit.

> But yes, there may still have problem isn't resolved, one of problem is
> pointed out when I discuss with YingXin about how to distinguish the Tag
> is about quantitative or qualitative. He think we need attribute for Tag
> to distinguish it. But the attribute isn't thing I like, I prefer leave
> that alone due to the user of placement API is admin-user.
>
> Any thought? or I'm too crazy at here...maybe I just need put this in
> the alternative section in the spec...

A resource class is not a capability, though. It's an indication of a 
type of quantitative consumable that is exposed on a resource provider.

A capability is a string that indicates a feature that a resource 
provider offers. A capability isn't "consumed".

BTW, this is why I continue to think that using the term "tags" in the 
placement API is wrong. The placement API should clearly indicate that a 
resource provider has a set of capabilities. Tags, in Nova at least, are 
end-user-defined simple categorization strings that have no 
standardization and no cataloguing or collation to them.

Capabilities are not end-user-defined -- they can be defined by an 
operator but they are not things that a normal end-user can simply 
create. And capabilities are specifically *not* for categorization 
purposes. They are an indication of a set of features that a resource 
provider exposes.

This is why I think the placement API for capabilities should use the 
term "capabilities" and not "tags".

Best,
-jay