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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/574e25ff-e2be-4328-94d1-2dc7ab25285b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
