| #! /usr/bin/env ruby | |
| require 'ripper' | |
| require 'json' | |
| unless ARGV[0] | |
| puts "Run this script with the name of a file, eg '#{$PROGRAM_NAME} /path/to/Puppetfile'." | |
| puts "If the file contains any Ruby methods, this will print them and then exit with an error code." | |
| exit 0 | |
| end |
| Facter.add(:puppet_report) do | |
| setcode do | |
| report = YAML.load_file(Puppet.settings['lastrunreport']) | |
| all_changes = report.resource_statuses.select { |title, rsc| rsc.changed } | |
| config_changes = all_changes.select { |title, rsc| rsc.resource_type != 'Notify' } | |
| { | |
| :time => report.time, | |
| :configuration_version => report.configuration_version, | |
| :status => report.status, |
| <% | | |
| Optional[String] $es_protocol = undef, | |
| Integer $es_major_version = 0 | |
| | -%> | |
| <% if $es_protocol { | |
| $_es_protocol = $es_protocol | |
| } | |
| else { |
| # A quick and untested implementation of a deferred_epp() function to abstract | |
| # the fiddly bits for deferring a template and render it agent side. | |
| # | |
| # Note: This depends on my find_template() PR. | |
| # | |
| # Note: If you're resolving variables agent side, then you'll have to defer | |
| # them as well. Pass them in via the $variables hash like this example: | |
| # | |
| # $variables = { | |
| # 'password' => Deferred('vault_lookup::lookup', |
If you're anything like the rest of us, you're suddenly being asked to make a lot of unplanned infrastructure changes and you haven't been given a lot of time to prepare. You're probably looking into some kind of automation so that you can keep up.
I've got a few tips on getting started and doing it in a way that's less prone to missteps along the way, especially if this is new ground for your team. And at the end is a quick tutorial on using Bolt for quick and easy automation wins.
| [~]$ cat tmp/append.pp | |
| class foo::bar($foo = []) { | |
| inline_template('<%= @foo.push("bar") %>') | |
| # do things | |
| inline_template('<%= @foo.push("foo") %>') | |
| # more things | |
| inline_template('<%= @foo.push("hello") %>') | |
| # even more things | |
| inline_template('<%= @foo.push("test") %>') | |
| notify{$foo.join(','):} |
| $variables = { | |
| 'password' => 'this is my passphrase'.node_encrypt::secret, | |
| } | |
| # compile the template source into the catalog | |
| file { '/etc/secrets.conf': | |
| ensure => file, | |
| content => Deferred('inline_epp', | |
| ['PASSWORD=<%= $password %>', $variables]), | |
| } |
| { | |
| "reported_compatibility": [ | |
| { | |
| "operatingsystem": "Archlinux", | |
| "version": "2020-01-01", | |
| "reporter": "@githubusername or email", | |
| "date": "2020-01-29", | |
| "support": "[email protected]" | |
| } | |
| ] |
| # This schema represents a regular site checkin. The service collects far more data, | |
| # but most of it remains in private datasets. The site_id is a hashed & anonymous value. | |
| # It cannot be reversed into something identifiable, even by us. We're limiting the data | |
| # in this table to minimize the ability to "fingerprint" a specific site. We explicitly | |
| # do not reveal node count in any way. | |
| # | |
| # This table provides only a highlevel overview of what user's codebases look like. It | |
| # can be used to answer questions like: | |
| # - are the people using my module on windows also using it on other platforms? | |
| # - does my module need to support a wide range of agent versions or can I tell people |
This is a quick report of all the GitHub repositories that we attempted to automatically upgrade to the Puppet 4.x function API. Many of these are stale and won't ever be noticed. And many of them are redundant forks, because for whatever reason, the GitHub API doesn't always identify forks reliably. 🤷
But it's a decent start!
Of interest is the fact that only roughly 900 module repositories contained