[openstack-dev] [nova] [scheduler] Use ResourceProviderTags instead of ResourceClass?

Alex Xu soulxu at gmail.com
Tue Aug 2 12:19:08 UTC 2016


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.

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...

Thanks
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160802/0843d4eb/attachment.html>


More information about the OpenStack-dev mailing list