Sending facts out-of-band natively

[Jon McKenzie]

Hi all,

We're thinking about implementing the "puppet facts upload" pattern to send facts up to the Puppetmaster (and into Foreman) out-of-band. Basically, we need a way to distinguish hosts which are alive, but just have their agent disabled (e.g. for troubleshooting), and hosts which are just not communicating with the Puppet infrastructure. We'd also like to keep up-to-date inventory information (we have a few dozen custom facts which we need to report on) despite the status (enabled/disabled) of the puppet agent.

It's surprising that this functionality isn't just accomplished automatically. But now, since Puppet 4 is deprecating the inventory service, the above solution will likely need to change. But the suggestion in the deprecation documentation that users simply write a script to parse the facts into the PuppetDB wire format and send them along seems like a pretty big step backwards from a usability point of view. It seems a little crazy that an end user has to deal with something so low-level to accomplish something that the Puppet agent can (and does) already do. The interface goes from 1 touchpoint (the 'puppet facts' command) to about four (get the current facts, format the facts into PuppetDB wire, retrieve the puppetdb server hostname from .. who knows where, configuration?, make the request to the PuppetDB API).

Is there room in this equation for a different agent run mode, one where the Puppet modules don't get applied, but the rest of the workflow (facts, etc.) still executes? Is there a better way of accomplishing this?

Thoughts?

Thanks

[Jon McKenzie]

For anyone that's interested, here's what I ended up doing:

I created a new Puppet face called 'maintenance' with an 'enter' and 'exit' action. When you 'enter' maintenance mode, it runs the 'config' face to set 'noop' to 'true' (by default in the agent section, but you can specify). This way, all of the standard agent processing logic runs (reports, etc.), except the host won't apply any config changes. Operationally, our team is just going to deprecate usage of 'puppet agent --disable' and instead use this custom command for maintenance/troubleshooting activities.