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

[abh]

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]

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]

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]

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

[thatch45]

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]

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]

I will get that patch in!

[madduck]

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]

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

[basepi]

Done.

[madduck]

@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]

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]

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.