[openstack-dev] [tripleo] Posibilities to aggregate/merge configs across templates
jtomasek at redhat.com
Tue Sep 11 22:43:04 UTC 2018
The problems you're describing are close to the discussion we had with
Mathieu Bultel here . Currently to set some parameters values as
ultimate source of truth, you need to put them in plan-environment.yaml.
Ignoring the fact that CLI now merges environments itself (fixed by  and
not affecting this behaviour), the Mistral workflows pass the environments
to heat in order in which they are provided with -e option and then as last
environment it applies parameter_defaults from plan-environment.yaml.
The result of  effort is going to be that the way deployment
configuration (roles setting, networks selection, environments selection
and explicit parameters setting) is going to be done the same by both CLI
and GUI through Mistral Workflows which already exist but are used only by
GUI. When you look at plan-environment.yaml in Swift, you can see the list
of environment files in order in which they're merged as well as parameters
which are going to override the values in environments in case of collision.
Merging strategy for parameters is an interesting problem, configuring this
in t-h-t looks like a good solution to me. Note that the GUI always
displays the parameter values which it is getting from GetParameters
Mistral action. This action gets the parameter values from Heat by running
heat validate. This means that it always displays the real parameter values
which are actually going to be applied by Heat as a result of all the
merging. If user updates that value with GUI it will end up being set in
On Tue, Sep 4, 2018 at 9:54 AM Kamil Sambor <ksambor at redhat.com> wrote:
> Hi all,
> I want to start discussion on: how to solve issue with merging environment
> values in TripleO.
> In TripleO we experience some issues related to setting parameters in heat
> templates. First, it isn't possible to set some params as ultimate source
> of truth (disallow to overwrite param in other heat templates). Second it
> isn't possible to merge values from different templates .
> Both features are implemented in heat and can be easly used in
> This doesn't work in TripleO because we overwrite all values in template in
> python client instead of aggregating them etc. orsimply let heat do the
> job .
> Example solutions are: we can fix how python tripleo client works with env
> and templates and enable heat features or we can write some puppet code
> that will work similar to firewall code  and will support aggregate and
> merge values that we point out. Both solutions have pros and cons but IMHO
> solution which give heat to do job is preferable. But solution with merging
> give us possibilities to have full control on merging of environments.
> Only few as a start: With both solutions we will have the same problem,
> porting new patches which will use this functionalities to older version of
> rhel. Also upgrades can be really problematic to new version. Also changes
> which will enable heat feature will totally change how templates work and
> will need to change all templates and change default behavior (which is
> params) to override behavior and also add posibilities to run temporaly old
> On the end, I prepared two patchsets with two PoC in progress. First one
> merging env in tripleo client but with using heat merging functionality:
> https://review.openstack.org/#/c/599322/ . And second where we ignore
> env and move all files and add them into deployment plan enviroments.
> What do you think about each of solution?Which solution should be used
> in TripleO?
> Kamil Sambor
>  https://bugs.launchpad.net/tripleo/+bug/1716391
>  https://bugs.launchpad.net/heat/+bug/1635409
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev