Open Stack

> Hi,

Hi Qiming
 
> 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.

I don't think that argument has been used. What Thomas said is that CFN having this feature is not a reason for having it in Heat.

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

Environments are not just a way to customize depending on the target cloud. They allow you to define values which are going to be available during your template instantiation, even on the same cloud. I see more them as complex parameters.

I think there was a push back on the review you mentioned because the use case is not super clear, and that using mapping for it clearly reduce reusability and portability. And the usecase you mentioned is *also* solved by environments. So currently you may understand where we're at.

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

I think that's interesting that you mentioned that, because Zane talked about a "variables" section, which would encompass what "conditions" and "mappings" mean. That's why we're discussing extensively about those design points, to see where we can be a bit more generic to handle more use cases.

Cheers,

-- 
Thomas