Open Stack

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

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.

Mainn

> 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
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>