Is it possible to ignore missing SLS files during pillar compilation?

[Warren Turkal]

I have a pillar top.sls that looks like this:

base:

  '*':

    - base

{% set service = salt['grains.get']('service_name', '') %}

{% if service %}

  'service_name:{{ service }}':

    - match: grain

    - services.{{ service }}

{% endif %}

The point of this is to allow a grain on the server determine which SLS files get compiled into the pillars. For example, if I add "service_name = blah", I would like services/blah.sls to be part of the pillar. This works find until service_name doesn't correspond to an existing file. I would prefer that if the pillar SLS doesn't exist that it just act like an empty file. Is there any way to do such a thing so that I can spin up machines in any service and the machine will just get a base configuration with no pillar info until the SLS file is created?

Thanks for the help,

wt

[Stephen Wood]

Try:

{% set service = grains['foo'] | default(None) %}

{% if service %}

Foo

{% endif %}

Nothing will be compiled on that host unless it has a value for that grain. 

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

--

Stephen Wood

www.heystephenwood.com

[Stephen D. Spencer]

On Thu, 2014-04-10 at 19:05 -0700, Stephen Wood wrote:
> Try:
>
>
> {% set service = grains['foo'] | default(None) %}

[...]

(in response to stuff)
[...]

> {% set service = salt['grains.get']('service_name', '') %}

[...]

Syntactically they appear to be expressing the same logic. Does the
former actually work?

The context that I've encountered this is having a general set of
defaults for a particular service /srv/base/pillar/nagios/client.sls,
for example, with /srv/base/pillar/nagios/clients containing individual
files where non-default pillar values are supplied.

I set up a reactor definition

set_pillar_host_files:
cmd.cmd.run:
- tgt: 'salt-master.*'
- arg:
- /srv/bin/pillar_update.sh {{ host }}

that triggers off of minion startup which does nothing more than touch a
file (named after the node) in each of several pillar directories such
that pillar compilation doesn't fail.

Is this running 40,0001 km west to get 1 km east? :)

-S


--
You know, I used to think it was awful that life was so unfair. Then I
thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve them?
So, now I take great comfort in the general hostility and unfairness of
the universe.

[Warren Turkal]

Thanks for the reactor workaround. It does seem like roundabout way to do it, but I can see why it would work. Seems like it might be a bit more complicated when using the git ext_pillar. It also seem like garbage collecting might be a little tricky.

In my environment, folks can just spin up instances under whatever service they want in our environment. Before, I was using the following config:

ext_pillar:

  - git: master git+ssh://sa...@example.com/example/example-salt-pillar.git

Also, I just tested the following config:

ext_pillar:

  - git: master git+ssh://sa...@example.com/example/example-salt-pillar.git

  - cmd_json: 'echo {}'

The intent of the config above is to ignore missing files. Clearly it's not working. Here's an example error message:

Specified SLS 'services.fjdsklfjs' in environment 'base' is not available on the salt master

That machine was spun up with the tag "service" = "fjdsklfjs" which got published to a grain "service_name" = "fjdsklfjs".

The file not existing is totally expected in this case, so I am wondering...is there a workaround so that I don't have to create a file and muck with git for every service that my users could possibly stand up?

FWIW, I also looked at the salt.pillar and salt.pillar.git_pillar modules, and it's not yet clear to me where the error ultimately comes from. I am guessing it's somewhere in the pillar compile, which I haven't looked into just yet.

Thanks,

wt

--

Warren Turkal

[Warren Turkal]

What is the benefit of this sytax over the syntax I used? I don't think the logic is materially different in this case consider that both None and '' are falsy.

FWIW, it sounds like you are referring to state SLS files that are compiled on the minions. I am referring to pillar data, which is compiled on the master. Basically, what I want is for a missing file in the pillar data to be treated as if were an empty file instead of failing.

wt

--
You received this message because you are subscribed to a topic in the Google Groups "Salt-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/salt-users/u6cZF8l_OwE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to salt-users+...@googlegroups.com.

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

--

Warren Turkal