accessing pillars using reactor or orchestrator

[Rémy Dernat]

Hi,

I want to read datas from my pillars during a reactor event. I am also doing it with my orchestrator. But, in both cases, it does not work.

I tried something similar that what I am doing for states, e.g. (in my reactor):

{% for container, container_info in salt['pillar.get']('containers', {}).iteritems() %}

 {% if container ==  the_container %}

update_pillars_{{ the_container }}:

  local.cmd.run:

    - tgt: {{ salt_master }}

    - arg:

      - python change_container_vals.py {{ the_container }} {{ container_info['host'] }} {{ container_info['ip'] }} {{ container_info['mac'] }} {{ NCORES }} {{ MEMORY }}

 {% endif %}

{% endfor %}

Any idea on how can I do that ?

Cheers,

Remy

[Seth House]

Pillar is minion-specific data. Since the Reactor and Orchestrate run
on the Master and not directly on behalf of any particular minion
Pillar is not automatically available.

There are a few approaches you can take:

1. Put the necessary Pillar data in the event payload when you send the event.

If you're sending an event from a minion you have local access to that
minion's Pillar data, so you can easily include it. This workflow is
directly supported when sending an event with `event.send` -- see the
`with_pillar` argument:

https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.event.html#salt.modules.event.send

2. Fetch the Pillar for a specific Minion by calling a Runner.

Since you're executing on the Master already you have quick access to
generating the Pillar for a given minion using either the `pillar.
show_pillar` runner or the `cache.pillar` runner -- unsure if there
are pros/cons for using one over the other.

https://docs.saltstack.com/en/latest/ref/runners/all/salt.runners.pillar.html
https://docs.saltstack.com/en/latest/ref/runners/all/salt.runners.cache.html#salt.runners.cache.pillar

There's also hacks like assigning Pillar to the hidden ID that the
master daemon uses or manually parsing Pillar files on the file system
using Jinja but those two are best avoided if possible.

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

[Rémy Dernat]

Hi Seth,

First of all, thank you for your answer. It was very useful even if I had already seen the "show_pillar" from the salt runner and I also already thought about sending more informations (including the whole pillar itself) from my minion. Anyway, it was very complete and helpful!

So, I have a reactor which is now working quite fine. In fact, my reactor is calling an orchestrator (because I needed a specific order of execution) which is running a python script and then apply a state. It is the easier solution that I found. The python script imports salt.client and salt.config. Everything is done inside it thanks to the salt API (getting the pillar, update the content with the mongodb module - and the "update_one" piece of the code I just wrote (see the associated PR): https://github.com/saltstack/salt/pull/35795 )

However, I also need to access a pillar in another orchestrator, and store a pillar value in a variable to use it later in my orchestrator. Any idea on this part ?

I am quite surprise that it is so difficult to access the pillars values when you try to access it from other things than a state or a python script.

Thanks,

Rémy

> email to salt-users+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
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+unsubscribe@googlegroups.com.

[Seth House]

On Tue, Aug 30, 2016 at 9:14 AM, Rémy Dernat <rem...@gmail.com> wrote:
> However, I also need to access a pillar in another orchestrator, and store a
> pillar value in a variable to use it later in my orchestrator. Any idea on
> this part ?

If you need to access the same Pillar value(s) from two separate
Orchestrate files, I would suggest putting the logic to fetch that
data into it's own file and then import that file via Jinja in both
Orchestrate files.

Or if you need to pass the Pillar data from the Reactor to Orchestrate
or from one Orchestrate to another, then your best bet is to use the
`pillar` kwarg when you invoke the second step.

> I am quite surprise that it is so difficult to access the pillars values
> when you try to access it from other things than a state or a python script.

Perhaps I misunderstand your use-case. It is very easy to access
Pillar values by simply calling either an execution module or a runner
module. Since Pillar data is minion-specific, and thus
location-dependent, the way you fetch that data depends on where the
script is being run. Accessing Pillar from a State or Python script is
done by calling one of those modules, and accessing Pillar data from
any other place is also done via calling one of those modules

[Rémy Dernat]

Hi Seth,

Sorry about my last answer. It works fine now. I do not know why exactly it did not work previously in my other orchestrator. This problem was not related to the first orchestrator.

It works with:

{% set container_str = 'bigmems:' ~ host ~ ':container:name' %}

{% set the_container = salt.pillar.get(container_str) %}

It did not work with (I usually used this way to retrieve a pillar and compare it in my states):

{% for container, container_info in salt['pillar.get']('containers', {}).iteritems() %}

 {% if container_info['host'] == host %}

  {% set the_container = container %}

 {% endif %}

{% endfor %}

I had to change a pillar, but that was not a big deal.

Thanks again,

Rémy

[Seth House]

Glad you got it working .Thanks for the update.

>> email to salt-users+...@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>
>

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