On 22/01/14 14:31, Tzu-Mainn Chen wrote:
On 2014/22/01 10:00, Jaromir Coufal wrote:
On 2014/22/01 00:56, Tzu-Mainn Chen wrote:
Hiya - Resource is actually a Heat term that corresponds to what we're
deploying within
the Overcloud Stack - i.e., if we specify that we want an Overcloud
with 1 Controller
and 3 Compute, Heat will create a Stack that contains 1 Controller and
3 Compute
Resources.
Then a quick question - why do we design deployment by
increasing/decreasing number of *instances* instead of resources?
-- Jarda
And one more thing - Resource is very broad term as well as Role is. The
only difference is that Heat accepted 'Resource' as specific term for
them (you see? they used broad term for their concept). So I am asking
myself, where is difference between generic term Resource and Role? Why
cannot we accept Roles? It's short, well describing...
True, but Heat was creating something new, while it seems like (to me),
our intention is mostly to consume other Openstack APIs and expose the
results in the UI. If I call a Heat API which returns something that
they call a Resource, I think it's confusing to developers to rename
that.
I am leaning towards Role. We can be more specific with adding some
extra word, e.g.:
* Node Role
* Deployment Role
... and if we are in the context of undercloud, people can shorten it to
just Roles. But 'Resource Category' seems to me that it doesn't solve
anything.
I'd be okay with Resource Role!
Actually - didn't someone raise the objection that Role was a defined term
within
Keystone and potentially a source of confusion?
Mainn
Yup, I think the concern was that it could be confused with User Roles.
However, Resource Role is probably clear enough IMO.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
