Never fall back to cfg_salt['master'] in minion config
#179
Conversation
blast-hardcheese
force-pushed
the
bugfix/178_master-configs-in-minion
branch
from
cc8d2e7 to
963f4f2
Compare
|
Do we know why this was originally written this way? Based on what I'm seeing, it should be able to be merged without worrying about breaking anything, since it's my understanding that its current implementation is broken |
blast-hardcheese
force-pushed
the
bugfix/178_master-configs-in-minion
branch
from
963f4f2 to
52044d2
Compare
|
@blast-hardcheese Looks like this one slipped through the cracks. Do any of those old pieces provide support for an older jinja release? It's the only reason I can think it was originally written that way. |
blast-hardcheese
force-pushed
the
bugfix/178_master-configs-in-minion
branch
2 times, most recently
from
6fcf97f to
12a4de1
Compare
blast-hardcheese
changed the title
cfg_salt['master']
blast-hardcheese
changed the title
cfg_salt['master']cfg_salt['master'] in minion config
|
@gravyboat Digging through the commit history unearthed 23fd8b6, I think processing |
|
Ah, one second-- found a failure case |
- When it's iterable, the minion could be running on the master - When it's a string, there's no advantage over just specifying `salt:minion:master`
blast-hardcheese
force-pushed
the
bugfix/178_master-configs-in-minion
branch
from
12a4de1 to
d730d4f
Compare
|
@gravyboat OK, this is ready to go. Now, on my minion, if I don't specify Also tested single and multi-master configs, seems to still work, so I think this is solid. |
…gs-in-minion Never fall back to `cfg_salt['master']` in minion config
|
Sounds good, thanks for getting this fixed up! |
if a special structure is required for master, it'll use whatever's defined in pillar.
Seems to resolve #178