make the configuration of engines specific to master or minion #259
Conversation
the engines are now configured using the following pillars: * salt.master.engines * salt.minion.engines instead of a global salt.engines pillar. Note: the pillar.example provided seems to assume this behaviour. (the pillar is salt.master.engines.slack and not salt.engines.slack)
|
@kakwa as far as i know, you can have an engine run on a single minion I my opinion it should stay split up this way as you otherwise will configure the engine on all minions, the same as the master. |
|
hummm, my pull request is actually implementing that split. Right now, the pillar used in the
Which means that there is no split. The |
|
what i say, you can have the case in which a specific minion needs to have an engine configured. For example, we're having one that listens to an sqs queue and does things off of that. Just saying, there are engines that may run on specific minions and if we're going with |
|
My PR does the exact opposite, it permits to configure engines on minion and master separatly. The current code uses the salt['pillar.get']('salt:engines')This is the current code, it's from https://github.com/saltstack-formulas/salt-formula/blob/master/salt/files/master.d/engine.conf#L4 |
|
@kakwa and @herisanu , I think we should have both options, For the salt minion: For the salt master: This way we keep the old option working without issues, and create a specific pillar engine for each type. |
Using the old salt.engines pillar and merging it with the new salt.[master|minion].engines pillar. This way, it doesn't break previous behavior and permits to define common engines on master and minion. In the merge, the salt.[master|minion].engines pillar takes precedence if conflict as it's the more specific pillar.
|
It's a good idea as it doesn't break the current formula behavior (and it's API). I've implementing a merge between common and specific pillar. I'm not sure it's the proper way to merge pillars however (sorry, I'm new to saltstack) |
|
@kakwa I have tested this only problem is that the pillar data: I think the same thing will happen with the data in salt:master:engines... f_defaults jinja needs to be aware that it should ignore salt:minion:engines / salt:master:engines keys. |
|
@kakwa solution: |
|
ping @gravyboat can this be merged? |
|
Done, thanks! |
|
thanks. |
the engines are now configured using the following pillars:
instead of a global salt.engines pillar.
Note: the pillar.example provided seems to assume this behaviour.
(the pillar is salt.master.engines.slack and not salt.engines.slack)
https://github.com/saltstack-formulas/salt-formula/blob/master/pillar.example#L83