Open Stack

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

http://docs.openstack.org/developer/heat/template_guide/openstack.html

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.

Separately, what we've got in the template is essentially a tree:

root:
 parameters:
 resources:
  thing:
    type: OS::Service::Thing
    ...
  thing2:
    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 :)

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud