Import top.sls data into jinja or import pillar data into top.sls

[Benoît L.]

Hi,

I am still new to Salt, but I am thinking using it more on our infrastructure.
However, I face a non blocking issue, and I am not sure what to use to solve this point. I will explain with a small example :

In my top.sls, I have :

base:
  '10.0.0.5':
    - dns.server
  '10.0.0.4':
    - dhcp.server

And my dhcpd.conf file (for the dhcp server) is generated using Jinja2.

include:
  - repo.client

server:

  dhcp:
    pkg.installed:
      - name: {{ pillar['pkgs']['dhcp'] }}
      - require:
        - sls: repo.client
       
  /etc/dhcp/dhcpd.conf:
    file:                                    
      - managed                              
      - source: salt://dhcp/dhcpd.conf.jinja
      - template: jinja
      - require:
        - pkg: {{ pillar['pkgs']['dhcp'] }}

And in the jinja file, I import the DNS ip from pillar :

option domain-name-servers {{ salt['pillar.get']('network:dns:ip') }};

Issue is: OK, I need here to render this jinja file the ip of the DNS server (and pxe server, etc). I can set these ip in pillar, but to me, setting dns.server in the top.sls means that this is this node that host the DNS server, and adding the same data into pillar is redundant. So, is there a way to import something like "Use ip from {On which host in top.sls is the dns.server set}" ? (not sure this is well explained)

If this is not possible this way, is there a way to use instead in top.sls the ip set in pillar to set the dns.server ? Something like :

base:
  {{ salt['pillar.get']('network:dns:ip') }}:
    - dns.server

I know this is absolutely different (top.sls is not a jinja file and is not rendered on the minion), this is just here as an example to explain my needs.

Does someone has an idea how to solve that ?

With my best regards

Ben

[Dmitry Golubenko]

В Втр, 09/02/2016 в 01:43 -0800, Benoît L. пишет:

actually top-file is jinja-file and you can use all grains/pillar magic
here.

>
> Does someone has an idea how to solve that ?
>
> With my best regards
>
> Ben

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

[Benoît L.]

I didn't know that ! :-)

I googled what you said it and found this example : http://imil.net/wp/2013/06/06/saltstack-dynamic-sls/

That's perfect, thanks a lot !

[Benoît L.]

Hello,

I still have one more questions related to what you said :

Jinja can be used in top files for salt and pillar. However, if I want to do something like this :
In state files : /srv/salt/top.sls :

base:
  {{ salt['pillar.get']('network:dns:ip') }}:

    - dns.server

And in pillar : /srv/pillar/top.sls :

base:
  {{ salt['pillar.get']('net
work:dns:ip') }}:

    - networkinfos

This doesn't work because. If I replace in /srv/pillar/top.sls by :

base:
  '*':
    - networkinfos

Then it is OK. How can I use Jinja in pillar files that use pillar data ?

With my best regards

Ben

[Megan Wilhite]

It looks like there is a feature request opened here: https://github.com/saltstack/salt/issues/6955

Is that related to what you are attempted to do? Looks like it is still an open feature request.

Thanks,

Megan

[Benoît L.]

Hi Megan,

My apologies for the delay of my answer.
Thank you for this answer.

Yes, this is related, with the small difference that I need this information in both Pillars and Salt States. Difficulty is that when you import files, in states it has to be distributed by the salt file server, so in /srv/salt for states in default configuration, and same for pillars in /srv/pillar. And relative path are not allowed in jinja import.

I found a workaround using the following :

in /srv, I add a file called network.sls

In this file, you can find this kind of structure :

network:
    repo:
        name: repo0
        ip: 172.16.0.13
    dhcp:
        name: dhcp0
        ip: 172.16.0.12

Then, in /srv/salt, I do a :
 ln -s ../network.sls network.sls
And the same in /srv/pillar :
 ln -s ../network.sls network.sls
Doing it this way allow me to migrate my /srv directory into another location if needed.

Then, in my /srv/pillar/top.sls, I use :

{% import_yaml 'network.sls' as vars %}
base:
  '{{vars.network.dhcp.ip}}':
    - repostuff
    - dhcpstuff

And in my /srv/salt/top.sks :

{% import_yaml 'network.sls' as vars %}
base:
  '{{vars.network.dhcp.ip}}':
    - repo.client
    - dhcp.server

And it works !! In fact, I only need to specify main network things inside this network file, which is shared.
Off course, it is a workaround, not a "clean" solution, but it is enough here as only few information need to be shared between top pillars and top states.

Salt is so flexible I want to use it at maximum to avoid redundant information.

Benoît