[openstack-dev] [nova] [scheduler] Use ResourceProviderTags instead of ResourceClass?
jaypipes at gmail.com
Tue Aug 2 18:12:47 UTC 2016
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
> 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
This is why I think the placement API for capabilities should use the
term "capabilities" and not "tags".
More information about the OpenStack-dev