Salt: Multi-environment Pillars

[debian112]

This is more of a question than bug.

We have an multi-environment shared salt-master. Each environment minion is hard coded to there respective environment. (environment: greentoads). I am looking to share my pillar data from base with greentoads. Is there a way to do that? If not, what other approach could I take.

master file:

pillar_roots:
  base:
    - /srv/salt/pillar/base
    - /srv/salt/base/pillar
  base_staging:
    - /srv/salt/pillar/base_staing
    - /srv/salt/base_staging/pillar
  greentoads:
    - /srv/salt/greentoads/pillar
    - /srv/salt/base/pillar
  greentoads_staging:
    - /srv/salt/base_staging/pillar
    - /srv/salt/greentoads_staging/pillar

base pillar top.sls file:

base:
  '*':
    - users.accounts
    - users.ids

[basepi]

Well the problem with the way you have it set up is the pillar files in base have the same path as the pillar files in greentoads. So when you tell greentoads to run users.accounts it will search the directories in order, find the file in /srv/salt/greentoads/pillar, and get the data from there. If you were to rename the base pillar files, then you could reference them, and when the master can't find the file in greentoads, it will look in the secondary /srv/salt/base/pillar directory. Make sense?

[debian112]

yes, make sense. I forget to remove that.

users.accounts and users.ids doesn't exist under greentoads.

The base top file is this:
base pillar top.sls file:

base:
'*':
- users.accounts
- users.ids

[debian112]

I run this on two different servers: One that has the environment None, and the other greentoads: salt-call pillar.get user_id -l debug

The None works, but the greentoads does not.

None:
[DEBUG ] Reading configuration from /etc/salt/minion
[DEBUG ] Using cached minion ID from /etc/salt/minion_id: utility01.greentoads.net
[DEBUG ] Configuration file path: /etc/salt/minion
[DEBUG ] Reading configuration from /etc/salt/minion
[DEBUG ] Decrypting the current master AES key
[DEBUG ] Loaded minion key: /etc/salt/pki/minion/minion.pem
[DEBUG ] Loaded minion key: /etc/salt/pki/minion/minion.pem
[DEBUG ] LazyLoaded .returner
[DEBUG ] Decrypting the current master AES key
[DEBUG ] Loaded minion key: /etc/salt/pki/minion/minion.pem
local:
----------
john:
----------
gid:
6012
uid:
6012

Greentoads:
root@web1:~# salt-call pillar.get user_id -l debug
[DEBUG ] Reading configuration from /etc/salt/minion
[DEBUG ] Using cached minion ID from /etc/salt/minion_id: web1.greentoads.net
[DEBUG ] Configuration file path: /etc/salt/minion
[DEBUG ] Reading configuration from /etc/salt/minion
[DEBUG ] Decrypting the current master AES key
[DEBUG ] Loaded minion key: /etc/salt/pki/minion/minion.pem
[DEBUG ] Loaded minion key: /etc/salt/pki/minion/minion.pem
[DEBUG ] LazyLoaded .returner
[DEBUG ] Decrypting the current master AES key
[DEBUG ] Loaded minion key: /etc/salt/pki/minion/minion.pem
local:

[basepi]

Hrm, sounds like there might be a bug there. We'll see if we can reproduce this issue.

[debian112]

Let me know if i can help with more testing with this.
root@utility01:/srv/salt/base/pillar/users# cat ids.sls
user_id:
john:
uid: 6012
gid: 6012

Thanks

[debian112]

Any head way on this, or is there a work around I can use?

[basepi]

Unfortunately no, not at the moment. We haven't had a chance to reproduce this yet.

[debian112]

Is there anything I can do for a work around?

On Mon, Jan 5, 2015 at 3:35 PM, Colton Myers [email protected]
wrote:

Unfortunately no, not at the moment. We haven't had a chance to reproduce
this yet.

—
Reply to this email directly or view it on GitHub
https://github.com/saltstack/salt/issues/19091#issuecomment-68775795.

Brandon Colbert

[basepi]

You might consider symlinking the base pillars into the directories of your other pillar data.

Edit: That might not work as cleanly as it did in my head. But investigating symlink workarounds would be worthwhile.

[debian112]

Any news on this one?

[basepi]

Sorry, we haven't had a chance to look into this further yet.

[debian112]

ok, thanks - I tried the symlink and that didn't work.

I am curious here. What will the cost be if we wanted to move this up the
list?

Thanks,

On Wed, Feb 11, 2015 at 6:36 PM, Colton Myers [email protected]
wrote:

Sorry, we haven't had a chance to look into this further yet.

—
Reply to this email directly or view it on GitHub
https://github.com/saltstack/salt/issues/19091#issuecomment-73988899.

Brandon Colbert

[basepi]

@debian112 I'm not involved in that kind of negotiation, but I'd be happy to introduce you to someone who can help with that kind of thing if you're interested. Feel free to e-mail me at the e-mail in my profile.

[rickh563]

@debian112,

SaltStack prioritizes Bug-Fixes and Feature-Requests based on a complex matrix of factors. When an Enterprise Customer of Salt submits a BF or FR, they do receive higher prioritization. When Salt is funded to fix bugs, the bugs receive higher prioritization. This is one of the clear benefits to becoming a customer of SaltStack. If you would like more information, please see http://saltstack.com/enterprise/ and give us a call.

Best Regards,
Rick Holzer

[debian112]

I have figured out how to solve this problem.
The solution is to active it under the other repo pillar area:

greentoads:
'*':
- users.accounts
- users.ids
Thanks