Pillar environment separation (yet again)

[Andrei-Florian Staicu]

Hi,

After seeing seeing contradictory information all over the internet, I decided to ask here, maybe somebody could finally clarify:

Using 2016.3.0, if I have

ext_pillar:

  - git:

    - base sal...@salt.saf.work:/home/saltgit/pillar.git:

      - env: base

    - test sal...@salt.saf.work:/home/saltgit/pillar.git:

      - env: test

and in each branch i have top.sls:

{{ env }}:

  '*':

    - default

{% if 'roles' in grains %}

  {% for role in salt['grains.get']('roles', []) %}

    - {{ role }}

  {% endfor %}

{% endif %}

and on the minion, in /etc/minion.d/environment.conf i put environment: test (yes, I saw the security warning about isolating on the master side),

shouldn't then the minion only get the pillar from the test branch? I saw that for the fileserver it works, but I would expect the pillar to work in almost the same way.

The final goal is not changing top.sls (like .. ever).

Thanks.

--

Beware of programmers who carry screwdrivers.

[Steve Hajducko]

The environment field is for the fileserver, not for the pillar.  You'll want to use the pillarenv config option instead.

Also, if you're specifying '*' in top.sls, that still means *everything*.  Environments are not hard boundaries.  I'm not sure it's going to work the way you want it to.

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

[Andrei-Florian Staicu]

I tried it with pillarenv, with the same result.

So I don't understand what't the purpose of having environments for pillars.

What's the difference in the pillar top file between:

prod:

  "prod*":

    - prodrole1

    - prodrole2

test:

  "test*":

    - testrole1

    - testrole2

and

everything:

  "prod*":

    - prodrole1

    - prodrole2

  "test*":

    - testrole1

    - testrole2

Thanks.

[Jeremy McMillan]

I think environments in Salt are supposed to be descendants of each other, with a heritage like Dev --> Test --> Prod.

Some pillars, like say an MTA (SMTP service) would be independent parallel setting. The dev pillar might always point to a localhost vagrant, and test might point to a special mail server that just puts all mail in one local mailbox regardless of address. Prod would stipulate a full blown Internet MTA. For this stuff, you would have devmail.sls, testmail.sls, and prodmail.sls pillar files.

Some pillars, like say somepackage-version, might stipulate a version peg for a package that your states will need to install. All minions would load the same somepackage.sls pillar file, but each would load it from the environment/git-version at that tag/branch.

Some stuff might be asserted the same everywhere, and stable enough to be everywhere, like maybe stuff for your local custom salt integration with your local non-salt tools specified in salt-extras.sls. Occasionally, you might need to override some of its pillars for sandbox environments, and you have chosen a pillar merge strategy carefully, so that you can load the same pillar.sls from base and environment where necessary.

BTW: I think a lot of people like to use the base environment as Prod, because it makes sense with the git branching workflow of merging features into the main branch as they become mature.

ergo... [my attempt at an illustrative example]

base:

  '*':

    - salt-extras.sls

prod:

  'prod*':

    - prodmail.sls

    - somepackage.sls

test:

  'test*':

    - salt-extras.sls

    - testmail.sls

    - somepackage.sls

[Colton Myers]

There's no effective difference as far as the minion is concerned. What's different is where the files are stored on the master. Each environment has its own folder on the master.

--  

Colton Myers

[Florian Ermisch]

I've made some suggestions about this last year [0]. The ideas like limiting a pillarenv to a set of keys found some approval but I don't think anyone tried implementing them yet.
I'm afraid it's an itch no one is yet annoyed enough by to have it scratched.
You may have to implement it yourself or convince someone to either do it for you or to pay/order someone to make this contribution ;)

Regards, Florian

[0]: https://groups.google.com/forum/m/#!topic/salt-users/h6ve2dalbII