Open Stack

Hi, 

Regarding the discussion about the adding of a native 'mappings' section
to HOT [1], which has been abandoned, I have some different thoughts for
the team to consider.  Maybe having that section added is not a bad
idea.

I do think we need a 'mappings' kind of functionality in HOT, to allow
users to make a from available options.  There are objections to adopt
this change:

  1) Too similar to CFN... Which should not be the criteria for
  excluding this.  We can use other section names, if we really believe
  that is an important factor to consider.
  
  2) The functionality can be covered by 'environments'.  That is
     where the team really concerns about.

My understanding to the item 2) is that people might have been somehow 
misled by the existing sample templates or the examples used in 
discussion (most of which were using imageId as an example).  

A 'mappings' section, IMO, provides the user an opportunity to make 
selections from many options, period.  Its usage is far beyond guest 
image Id selection. Not all use cases are suitable to be expressed as 
'environments'. 

As the name suggests, 'environment' is a concept to decouple a
template from the cloud/host/guest where it is created.  It helps
promote portability or reusability of the template.  If you have
some settings that will change between clouds, or different guest
OS. 'environment' is the ideal place to put those variances. 

However, a 'mappings' section is about functionality, not usage
scenario.  It can be treated as a subsection of 'parameters', to
make a template even more reusable when the stack can be used with
different resources (say, softwareconfigs, cloudconfigs, different
sources for get_file etc.).  

Say I have three DB backends to choose from, for my application [2].
The DB backend is better treated as a component of the application, 
instead of part of the environment.  A 'mappings' section can be 
used for a quick selection of OpenStack level options (such as 
scaling policies, security groups, different templates for a nested 
stack, different versions of external templates residing on a GIT
website...) or any application-level options (such as a different
SoftwareDeployment for the same SoftwareConfig), irrespective to which
cloud (the 'environments', my understanding) is hosting the stack.  

Speaking of offering options for selection, there is another proposal on
adding conditional creation of resources [3], whose use case to enable
or disable a resource creation (among others).  My perception is that
these are all relevant enhancements to the reusability of HOT templates,
though I don't think we really need very sophisticated combinatory
conditionals.

Regards,
  - Qiming

[1] https://review.openstack.org/#/c/81918/
[2]
http://lists.openstack.org/pipermail/openstack-dev/2014-April/031712.html
[3] https://review.openstack.org/#/c/84468/