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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
