The 'do update' pattern in map.jinja is not working properly for nested defaults when overriden by lookup

[hkbakke]

I think the map.jinja pattern is not working ideally as it is now as it completely falls apart if you have nested defaults.yaml file and you try to use lookup to change a single dictionary value somewhere in deeper levels of the default config.

The problematic part is the dictionary update where default_settings is updated with os_family_map as it does not do deep merging.

My main issue with this is not that I can't work around it, it's just that this template is for many seen as "best practice" and reused, and this issue is rather hard to diagnose as it works most of the time, until it just doesn't just because you added a lookup value to a formula with important nested defaults.

The most intuitive solution I have seen is using the base attribute of grains.filter_by. Is there any reason that the base attribute of grains.filter_by is not used today?

A pattern like this has none of these issues as far as I have experienced:

map.jinja:

# -*- coding: utf-8 -*-
# vim: ft=jinja

{## Start with defaults from defaults.yaml ##}
{% import_yaml 'template/defaults.yaml' as default_settings %}

{##
Setup variables using grains['os_family'] based logic, only add key:values
that differ from what is in defaults.yaml
##}
{% set base_settings = salt['grains.filter_by'](
  default_settings,
  , grain="os_family"
  , merge=salt['pillar.get']('template:lookup')
  , base='template')
%}

{## Merge in template:lookup pillar ##}
{% set template = salt['pillar.get'](
        'template',
        default=base_settings,
        merge=True
    )
%}

defaults.yaml:

# -*- coding: utf-8 -*-
# vim: ft=yaml
template:
  pkg: template
  config: '/etc/template'
  service:
    name: template

Debian: {}
Suse: {}
Arch:
  pkg: template-arch
RedHat:
  config: /etc/template.conf

An additional benefit is that since all the default settings is stored in defaults.yaml the os family map is much easier to write.

[aboe76]

see pr #20

[myii]

@hkbakke Thanks for your report. This has been resolved by both #20 and #25.