Skip to content
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

Closed
abh opened this issue Oct 18, 2012 · 14 comments
Closed

cmd_yaml pillar can't be used on a per minion basis #2276

abh opened this issue Oct 18, 2012 · 14 comments
Assignees
Labels
Feature new functionality including changes to functionality and code refactors, etc.
Milestone

Comments

@abh
Copy link
Contributor

abh commented Oct 18, 2012

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?) :-)

@thatch45
Copy link
Contributor

Heh, good call, the cmd_yaml is primarily a proof of concept, I will look into this.
Do you have a specific use case to ref?

@abh
Copy link
Contributor Author

abh commented Oct 18, 2012

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.

@thatch45
Copy link
Contributor

Thanks :)
This is a crazy easy addition, the hard part of deciding what all should be passed in and how.

@ghost ghost assigned thatch45 Nov 8, 2012
@thatch45
Copy link
Contributor

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.
For now I am going to move this to approved for the future pending discussion.

@madduck
Copy link
Contributor

madduck commented Jan 22, 2013

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?

@thatch45
Copy link
Contributor

I will get that patch in!

@madduck
Copy link
Contributor

madduck commented Feb 1, 2013

The docs at https://salt.readthedocs.org/en/latest/ref/configuration/master.html#ext-pillar use /bin/cat with cmd_yaml.py; this will now no longer work. I suggest to replace it with

cmd_yaml: /path/to/script/returning-yaml-for-hostname

@m-o-e
Copy link

m-o-e commented May 29, 2013

Please re-open this ticket. The above fix was reverted in 4ec6722.

@basepi
Copy link
Contributor

basepi commented May 29, 2013

Done.

@basepi basepi reopened this May 29, 2013
@madduck
Copy link
Contributor

madduck commented Aug 27, 2013

@thatch45 @basepi: We either have to make an incompatible change to cmd_yaml, or let this issue go. However, since Pillar data are specific to a node, and right now the command has no way to figure out which minion's Pillar data to serve, the current interface is rather useless. Correct me if I am wrong.

If you want, then I can create a patch that catches run-time exceptions from cmd.run and falls back to the old behaviour. Though I really don't think we need to be this careful, I cannot imagine any real use-case with the status quo.

@mbarrien
Copy link
Contributor

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.

@madduck
Copy link
Contributor

madduck commented Jan 22, 2014

There is no way to parse **kwargs to the external pillar without breaking the existing interface. I think the simplest backwards-compatible solution would be to put the minion ID into an environment variable.

@Grokzen
Copy link

Grokzen commented Jun 5, 2015

This could be closed based on this PR #22461 that is now in develop branch.

@basepi
Copy link
Contributor

basepi commented Jun 5, 2015

Awesome, thanks!

@basepi basepi closed this as completed Jun 5, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature new functionality including changes to functionality and code refactors, etc.
Projects
None yet
Development

No branches or pull requests

7 participants