New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

salt '*' config.get environment #7088

VertigoRay opened this Issue Sep 6, 2013 · 4 comments


None yet
2 participants

VertigoRay commented Sep 6, 2013

When I run salt '*' config.get environment from the master, all of my minions return None.

Expecting something like one of these:

  • 'base'
  • 'dev'
  • ('dev','base')

A couple people on IRC reported the same thing. Since None is the default value, I'm assuming it's not overwritten properly by the class.

I'm not sure which class (RemotePillar or Pillar) is actually being used. Assuming Pillar since it's the default, and I don't have a file_client option on my /etc/salt/master file. However, I'm just assuming that's where the file_client option is since I'm not sure where get_pillar is called from.

If it is RemotePillar, then I think None is the only thing that will ever return because of:

If it is Pillar, then I think the break down follows this path:

... but realistically, I don't know where get_pillar() is called from. This means that I neither know what the opts var nor the env var looks like or how it's generated. So you can pretty much dismiss my Pillar and RemotePillar analysis above. /shrug

Wish I could have simply submitted a pull request, but I'm not sure where to begin on this one. Likely due to still be wet behind the ears with saltstack -- only been using this for a few weeks.

# salt --versions-report
           Salt: 0.16.3
         Python: 2.7.2 (default, Oct 11 2012, 20:14:37)
         Jinja2: 2.7.1
       M2Crypto: 0.21.1
 msgpack-python: 0.3.0
   msgpack-pure: 0.1.3
       pycrypto: 2.6
         PyYAML: 3.10
          PyZMQ: 13.1.0
            ZMQ: 3.2.3

This comment has been minimized.


basepi commented Sep 6, 2013

Wait, so what are you trying to do? Where are you overwriting the default value of environment? Because I would expect my minions to return None, as that is the default.

Putting environments in your top.sls file doesn't actually change the configuration for the minions. It defines environments, targets minions which should be in those environments, but won't change the output of salt '*' config.get environment.


This comment has been minimized.


VertigoRay commented Sep 7, 2013

Looks like it's not a bug then. Sorry for my confusion on how Salt sets pillar variables, I do wish it was more thoroughly discussed in the Master Config in Pillar section of the docs.

The only two options I have in the minion config file are id and master. Master doesn't show up in salt '*' pillar.items, but does return the correct value when you use salt '*' config.get master.

Why is the recommended way to manage environments is to isolate via the top file? Wouldn't the best way be to put a machine in an environment be:

environment: dev
    - match: pillar

Could even probably do it with a state, something like:

{% set dev = ['TESTCOMP0001'] %}

{% if grains['nodename'] in dev %}
    - text: "environment: dev"
{% else %}
    - text: "environment: prd"
{% endif %}

This comment has been minimized.


basepi commented Sep 9, 2013

Well, technically minions can be in multiple environments, so that's one reason. You also may want to change their environments without restarting the minion. (Config changes require minion restart.)

You can define node groups (similar to what you're trying to do with environments) and target that way as well:


This comment has been minimized.


VertigoRay commented Sep 10, 2013

Odd that you set that in the master config file -- does that require a restart of the master? I would think you would want that more malleable, and sitting next to top.sls.

I think I'll use a custom grains to set an environment grain that I can reference in my environment:

Thanks so much for the feedback!

@VertigoRay VertigoRay closed this Sep 10, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment