[openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 - Roles
tzumainn at redhat.com
Thu Jan 23 14:12:38 UTC 2014
----- Original Message -----
> On 23 January 2014 21:39, Jaromir Coufal <jcoufal at redhat.com> wrote:
> > On 2014/22/01 19:46, Tzu-Mainn Chen wrote:
> > So... For now, the attributes are:
> > - Name
> > - Description
> > - Image (Image was discussed on the level of a Role, not Node Profile)
> > - Node Profile(s)
> > Future:
> > + Service Specific Configuration (?)
> > + Policies (spin up new instance, if...)
> Is the list of 'resource types' in heat. You can see that a resource
> is [roughly] anything that can be addressed by an API. The instances
> we deploy are indeed resources, but not all resources are instances.
> It seems to me that there are two ways to think about the naming problem.
> A) What if we were writing (we're not, but this is a gedanken) a
> generic Heat deployment designer.
> B) What if we are not :)
> If we are, not only should we use heat terms, we should probably use
> the most generic ones, because we need to expose all of heat.
> However, we aren't. So while I think we *should* use heat terms when
> referring to something heat based, we don't need to use the most
> generic such term: Instances is fine to describe what we deploy.
> Instances on nodes.
The issue I have with Instances is that it gets fairly confusing when
working within the UI. From the UI, we have calls to the Heat client
grabbing Resources; we also have calls to the Nova client from which we
get Instances. When we get information about the Overcloud, we query
from Stack -> Resources -> Instance -> Node
So calling it Instance<something> would imply (to me) that a Resource
has no specificity - which I don't think is the case, as there are
attributes to a Heat Resource that mark it as a Compute/Controller/whatever.
Calling it Instance<something> and explaining that it *does* apply to a
Heat resource (but that we just renamed it) feels simply confusing.
> Separately, what we've got in the template is essentially a tree:
> type: OS::Service::Thing
> type: OS::Service::Thing
> And Tuskar's job is to hide the plumbing from that tree (e.g. that we
> need an OS::Heat::AccessPolicy there, because there is a single right
> answer for our case, and we can programatically generate it.
> The implementation is going to change as we move from merge.py to HOT
> etc, but in principle we have one key under resources for each thing
> that we scale out.
> I don't know if that helps with the naming of things,but there you go :)
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev