[PUP-3918] There should be a Node Terminus that uses a local YAML file like an External Node Classifier. Created: 2015/01/28  Updated: 2017/05/18  Resolved: 2017/05/15

Status: Closed
Project: Puppet
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Normal
Reporter: redmine.exporter Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: redmine
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:

 Description   

I wrote a node terminus that pulls the node data from a local file (/etc/puppet/node.yaml) in the same format as the external node classifier. I use this in order to do experiments on a single node by running stand-alone puppet, in an environment that usually uses an external node classifier. With a local copy of the node classifier output, and a local copy of the manifests, my development cycle is: edit the node.yaml, edit the manifests, run puppet, repeat; then merge working changes up. I also use this for entirely stand-alone hosts, such as Amazon EC2 instances launched with an external node classifier Yaml file passed as User Data.

Local Yaml node terminus:
https://github.com/brothers/puppet/commit/251e46cadc8d366404c74d1195b874f55a2a0b66

I also wrote an mcollective client/agent pair to execute the classifier and copy the output to a local file on the node.

Local Yaml client/agent:
https://github.com/brothers/mcollective-plugins/commit/59ecd42fa8c9051f5f0abc83ee10d7ba445b5f57

I would like to receive feedback on this, before I clean it up and write tests for it.



 Comments   
Comment by Matthias Saou [ 2015/01/28 ]

I would also really like this feature. I tried the yaml node_terminus, and as some others have mentioned, it's not suitable because it expects some other kind of YAML.

My use case is having a custom ENC, where changes are difficult to make since it's on production, and developers want to be able to quickly replicate a node's entire state. It's trivial to extract a node's YAML from the ENC, and once a developer has it, it needs to be used with "puppet apply".

Here is my current workaround :

$ cat .cat
#!/bin/bash
# Silly script, required for now. See :
# https://tickets.puppetlabs.com/browse/PUP-3918
exec cat `dirname $0`/apply.yaml

And I execute something along these lines :

puppet apply -v --show_diff \
  --hiera_config=/dev/null \
  --modulepath=$PWD/modules \
  --logdest=console \
  --logdest=/var/log/puppet/puppet.log \
  --node_terminus=exec \
  --external_nodes=$PWD/.cat \
  apply/site.pp

It actually works

Comment by Henrik Lindberg [ 2015/01/28 ]

Does this have to be in puppet itself as opposed to being in a module?

Comment by Matthias Saou [ 2015/01/29 ]

I personally don't really care, though I think this would be nice to have "out of the box" given how trivial it seems to me to just read the yaml from a file.

Also, the use case of wanting to copy/paste as-is an ENC YAML output to debug using puppet apply seems quite valid to me : It's so much easier and less error prone than to have to translate the YAML to Puppet DSL, or even to Hiera YAML since the ENC classes+parameters hash needs to be split up into a classes array + separate parameters for the Hiera auto lookup (unless I'm mistaken).

Comment by Eric Delaney [ 2017/05/15 ]

Thank you for filing this issue. However, we believe this change represents a technical direction that we have decided not to follow in Puppet. As such, we are closing this as “Won’t Do”. If any watcher believes this is an error, please add a comment explaining.

Generated at Wed Nov 13 12:54:44 PST 2019 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.