Best practice pillar usage, merge or overrride global and node data?

[Gerard Petersen]

Hi All,

I'm halfway through my 'chef to salt' migration and had an epiphany in regards to pillar usage. Look at the pillar data below:

# pillar/servers/srvxx.sls

node_info:

  area: staging

  role: webserver

  primary_ip: 192.168.2.13

node_pkg:              << rename

  ossec:

    agent_key: 001 srvyy 192.168.2.13 bacc2754a810220d0c#######FAKE##########c3732f39b2044f5714

# pillar/servers/defaults.sls

global_info:

  backupserver_ip: 192.168.2.5

defaults_pkg:              << rename

  ossec:

    server_name: srvxx.internal.nl

Renaming node_pkg and defaults_pkg in the different sls files to the same name would flatten the pillar data namespace usagesignificantly and giving me this:

# runtime pillar example

pkg:

  ossec:

    agent_key: 001 srvyy 192.168.2.13 bacc2754a810220d0c#######FAKE##########c3732f39b2044f5714

    server_name: srvxx.internal.nl

Only requirement being, choose your pillar tags/names carefully. My question: Is there a merge or an override in case of a name clash? .. And can I influence this?

Thanx a lot.

Kind regards,

Gerard.

[Luminous Salt]

On 2014-10-14 08:47, Gerard Petersen wrote:
> Hi All,
>
> I'm halfway through my 'chef to salt' migration and had an epiphany in
> regards to pillar usage. Look at the pillar data below:

Consider using reclass for ENC and sensible pillar management - reclass
does classes, state/pillar mapping, and merging of the information in
sensible ways.

https://github.com/madduck/reclass

[Mike Place]

In 2014.7 you can select your pillar merge strategy using the option 'pillar_source_merging_strategy'. Current options are 'recursive', 'aggregate', 'smart' and the old behaviour of 'overwrite'.

I don't know if this is documented right now but if it's not it should be done soon. In the meantime, the relevant code for each strategy is in salt/pillar/__init__.py

-mp

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ryan Lane]

It's documented, but missing the bit about overwrite: <http://docs.saltstack.com/en/latest/ref/configuration/master.html#pillar-source-merging-strategy>.

[Mike Place]

Good catch. I will add that to the docs. Thanks Ryan!

-mp

[Bruce Wang]

Hi Luminous,

Any tutorial/example on how to use reclass with Salt?

 

I've read the reclass's docs but still quite confused.

Thanks!

--
simple is good
http://brucewang.net
http://twitter.com/number5

[Gerard Petersen]

Hi Mike,

Thanx for you reply. Is 2014.7 an awaited version? .. It's 6 points higher then the latest on pypi (2014.1.11) and I'm on 2014.1.10 (Hydrogen).

Regards,

Gerard.

[Gerard Petersen]

Hi Luminous,

All-though the ENC solution looks awesome, with only a dozen nodes the solution seems bigger then the problem for now.

Will keep it in mind though.

Regards,

Gerard.

[Gerard Petersen]

Hi all,

I just installed 2014.7RC3 from git and merging is running smooth. Only thing is the order. How can I control (make sure) the node overrides the global one and not the other way around. Is that controlled in the pillar/top.sls?

# global sls snip

defaults:

  rkhunter:

    rtkt_file_whitelist: /usr/bin/sometool

# Node sls snip
node:

  rkhunter:

    rtkt_file_whitelist: /usr/bin/sometool /usr/bin/othertool

[Dennis Jacobfeuerborn]

FYI I'm currently putting some finishing touches on a system called Varstack that basically works similar to hiera but is a better fit for salt and allows these kinds of overrides and merges in a controlled way. It's probably gonna take me a could of days though to get Varstack itself packaged and then I'll submit a pull-request for an ext_pillar module that makes this available as pillar for salt.

On Tuesday, October 14, 2014 2:47:49 PM UTC+2, Gerard Petersen wrote: