-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd_yaml pillar can't be used on a per minion basis #2276
Comments
Heh, good call, the cmd_yaml is primarily a proof of concept, I will look into this. |
I have a couple dozen hosts that need just a few configuration keys each (IP addresses to bind on for a couple services). Editing pillar/top.sls and pillar/hostname.sls (or whatever) just for that feels like a lot of overhead. With an external command I can put it in one file and have my external command do a tiny bit of filtering and also programmatically provide defaults (some data I can lookup in DNS) etc. |
Thanks :) |
I am leaning towards not changing this. The main reason for the external pillar system to to deliver the capability to get this data to the pillar system. |
I don't understand why you are opposed to changing this. ext_nodes gets the node ID, so why shouldn't cmd_yaml? https://groups.google.com/d/msg/salt-users/R_jgNdYDPk0/u2xAwdWiu3UJ has the patch, this is all that's required, won't break existing code, and I cannot see a reason why that wouldn't be enough — and if it isn't, then maybe we should talk about extending the interface? |
I will get that patch in! |
The docs at https://salt.readthedocs.org/en/latest/ref/configuration/master.html#ext-pillar use
|
Please re-open this ticket. The above fix was reverted in 4ec6722. |
Done. |
@thatch45 @basepi: We either have to make an incompatible change to If you want, then I can create a patch that catches run-time exceptions from |
What about adding a **kwargs argument to the ext_pillar for cmd_yaml/cmd_json? Something like a "template: jinja" or an even simpler "pass_args: True" could enable this behavior, and by default it is disabled, allowing backward compatibility. Even adding this simple feature will remove the need for me to have 3 custom external pillars. |
There is no way to parse |
This could be closed based on this PR #22461 that is now in develop branch. |
Awesome, thanks! |
It seems like a cmd_yaml pillar can only setup "global" data as it doesn't get the minion id passed as a parameter like the ext_nodes command does.
(Unless I missed something in which case maybe the documentation could be expanded?) :-)
The text was updated successfully, but these errors were encountered: