CODEWITHSUNDEEP
salt-project
Balding VoIP Engineer
Balding VoIP Engineer

Reputation: 3

SaltStack - mine.get is able to grab mine_function data from master, but not in .sls or jinja variable

I hope you can help me with a rather frustrating issue I have been having. I have been trying to remove static config from some config files and move this to Pillar/Mine data using Salt-Stack.

Everything is going well, with the exception of 1 specific task.

This is grabbing data (custom grain) from 3 specific minions to make 3 different variables in an .sls (context) or a jinja file (direct variable) on other minions, but I cannot seem to get it to work.

(My scenario is flexible as I can call this in either a state file or jinja variable in a config file.)

This is on AWS EC2 instances, but can be replicated away from AWS in my lab. The grain I need is: "public_ipv4" and the reason I cannot use the network.util in salt runner is because this is NAT'd and the box doesn't have a 2nd interface with the public IP assigned to it. (This cannot be changed)

Pillar data works and I have a init.sls for the mine function:

mine_functions:
  grains.item:
    - location
    - environment
    - roles
    - srvtype
    - instance
    - az
    - public_ipv4
    - fqdn
    - ipv4
    - ipv6

(Also the custom grain: "public_ipv4" works being called by the minion so I know it is the not the grains themselves being incorrect.)

When targeting via the master using the below it brings back the requested information:

my-minion:
    ----------
    minion-with-data-i-want-1:
        ----------
        az:
            c
        environment:
            dev
        fqdn:
            correct_fqdn
        instance:
            3
        ipv4:
            - Correct_local_ip
            - 127.0.0.1
        ipv6:
            - ::1
            - Correct_ip
        location:
            correct_location
        public_ipv4:
            Correct_public_ip
        roles:
            Correct_role
        srvtype:
            None

It is key to note here that the above comes from:

salt '*globbed_target*' mine.get '*minions-with-data-i-need-glob*' grains.item

This is from the master, but I cannot single out a specific grain by using indexing or any args/kwargs etc.

So I put some syntax into a state file and some jinja templates and I cannot get it to work. Here are a few I have tried so far:

Jinja:

{% set ip1 = salt['mine.get']('*minion-with-data-i-need-glob*', 'grains.item')[7] %}

Above returns nothing.

State file:

- context:
    - ip1: {{ salt['mine.get']('*minions-with-data-i-need-glob*', 'grains.item') }}

The above returns a dict error:

Context must be formed as a dict

Running latest salt-minion/master from apt.

Steps I have taken:

Running: salt '*' mine.update after every change and checking with: salt '*' mine.valid after every change and they show.

Any help is appreciated.

Upvotes: 0

Views: 828

Answers (1)

whytewolf
whytewolf

Reputation: 704

This looks like you are running into a classic problem. Not knowing what you are getting as the return value.

first your {# set ip1 = salt['mine.get']('*minion-with-data-i-need-glob*', 'grains.item')[7] #} returns nothing because it is a jinja comment. {% set ip1 = salt['mine.get']('*minion-with-data-i-need-glob*', 'grains.item') %}

the next problem you have is that you are passing a list to context. when it is supposed to take a dict. the error isn't even related to mine.

try this instead

- context:
    ip1: {{ salt['mine.get']('*minions-with-data-i-need-glob*', 'grains.item') | json}}

next learn to use slsutil.renderer to look at how things are rendered. such as salt minion slsutil.renderer salt://thing/init.sls default_renderer=jinja

Upvotes: 0

Related Questions