Salt-Master Managed Grains...Or just pillars?

[Brandon Graves]

Hello All,

I'm losing my mind here, so hopefully someone can shed some light on things, since I can't seem to find anyone else that has talked about this.

So I have a few states that different servers will get different values for, based on the server role. Initially I was assigning these values by creating pillars and assigning the pillars in the top file.

ie a Server might get the pillar:

Roles:
   - Admin: True

or

Roles:
  - webserver: True

or

Roles:
  - webserver: True
  - Admin: True

Or any other combination based on roles that may exist.

I then had the thought that, in all examples in the salt documentation: Roles are handled via grains, and on reflection that makes a lot of sense to me. Pillars for storing data, Grains for filtering states...

The thought of manually editing grain files on each server though, seems rediculous. So i was looking at the Salt.states.grains functionality... But I cannot get them to function in a manner that I feel is sane.

So what I'm attempting to do is have several different states, that can be assigned to different servers, that will modularly assign roles to servers.

So server A could be assigned: roles.admin, and roles.webserver, and end up with an /etc/salt/grains file that looks like Example 3 from above.


The problem is, the multiple states don't seem to be modular.

If i create a state that looks like:

role-admin:
  grains.present:
    - name: roles
    - value:
      - admin

And another:

role-webserver:
  grains.present:
    - name: roles
    - value:
      - webserver

One state works correctly, the other spits out:

The key 'roles' exists but is a dict or a list. Use 'force=True' to overwrite.

Alternatively, I have attempted using grains.append, but that ends up adding a ton of extra copies every time highstate is triggered...

I managed to get the functionality i wanted by doing 3 states

1)
role-base:
  grains.list_present:

     - name: roles
     - force: True
     - value:
        - base

and then the other 2 roles above, set as "grains.append" with a "require: grains: roles" To force the order...

This however doesn't act in a stateful way, and re-applies the state every time highstate is run. and if i Remove "force" from the role-base, it just keeps adding the other two roles to it indefinitely.

The whole thing is also very fragile, and if anything is modified, i get back to the original error, and have to delete the grains file and start from scratch.


So basically, is there something i'm missing here? is there a way to manage grains remotely without it being just ridiculously organized? SHould I just use Pillars for this? It's really frustrating. I feel like configuring pillars is easy as can be, and that If i just do things in what feels like "the wrong way" I have zero trouble, but by trying to do things in what seems like "the right way" I have to either A) manage the grains files manually. B) Have things non-stateful, or C) have like...A million states that spell out each individual possible combination of roles, and assign them individually.

Is there a better way?

Thank you so much for any tips/tricks/advice.

--bmgraves

 

[Nicholas Capo]

I much prefer using pillars for this, for a few reasons:
1. In a security context, pillar can't be manipulated by the minion (e.g. to see secrets it shouldn't be able to see), the roles might not be sensitive, but other pillar data (assigned per role) might be.
2. To automatically set a role grain, I still need a source of truth for identifying the minion, and it's easy to have that source be outside you salt repo.
3. I only need to look at the top files to see all the roles etc that a minion will be assigned.

Sorry I'm not more helpful with your /actual/ questions,

Nicholas

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/e5ddfc89-99ab-44d3-a97e-f3b1ca87b9ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[BKeep]

You can try an onlyif check like `grep webserver /etc/salt/grains` to test for the specific grain.

I use grains.append whenever a server is created. On a small scale that works doing it via `salt -C 'esnode-data*' grains.append roles es-cluster` etc. I have found using append seems to work better for me vs set. Some servers have multiple roles `salt -C 'graylog*' grains.append roles mongodb` and salt -C 'graylog*' grains.append roles graylog`

This results in a grains file that looks like this

[root@esnode00 ~]# cat /etc/salt/grains
roles:
- es-cluster
- mongo

Regards,
Brandon