Script to track orphaned resources

[Manuel Quiñones]

Hello,

I'm working on a utility script to track orphaned resources.  With orphans I mean: resources that were previously managed by Puppet, but they no longer are.  I want to track those while I do a refactor in my manifests.

Here is the script I wrote:

https://gist.github.com/manuq/eec269ce7ba00974f46e

It is based on some assumptions, and here is my question: are these assumptions correct?

- Puppet generates the following files on each run, even when called with --noop:
- last_run_report.yaml: contains the resources currently managed, in full detail (serialized Puppet objects)
- state.yaml: contains the resources Puppet ever managed since the file was created, only their name and some timestamps "checked" and "synced"
- last_run_summary.yaml: among other things, contain the timestamp of the run, and the total time it took

Based on that, I have two methods that output the orphans:

Method 1: use state.yaml and read the "checked" timestamp. If it was not checked in the last run, then it is an orphan.
Method 2: orphans are the subset of resources that are contained in state.yaml and are not contained in last_run_report.yaml.

Critics and suggestions welcome.  Also I hope this can be useful to others.

Cheers,

PS Note that this topic was discussed earlier in May.  I took it as initial reference:

https://groups.google.com/forum/#!searchin/puppet-users/orphan/puppet-users/ghKfRBkPD5A/m7KTeymd2XwJ

[Garrett Honeycutt]

Hi Manuel,

Your plan is quite clever though if your goal is to refactor your puppet
modules and not leave anything out, spec tests are the way to go.

http://rspec-puppet.com/tutorial/

Best regards,
-g

--
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658

[Martin Langhoff]

For context... Our puppet setup is complex, with many behaviors controlled by facter facts, in part controlled by a .INI file that support personnel can edit. We manage thousands of VMs.

So unit tests are interesting but offer very limited coverage. Tracking orphans on live nodes is much more comprehensive. In particular it catches things folks haven't thought about.

For example, a node had a class webserver applied. For whatever (bad) reasons that class is no longer applied... hey this node has apache installed and running, but now unmanaged! We sure as heck want an alert over that.

Any long-term puppet infra has high risk of orphaned resources. There's so many ways this can happen.

cheers,

m

--
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 puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/53F66DE9.4020705%40garretthoneycutt.com.
For more options, visit https://groups.google.com/d/optout.

[Jason Antman]

Two things that I've come across that help this situation:

- for new modules, rspec tests

- for existing modules, https://github.com/ripienaar/puppet-catalog-diff - I generate a catalog with the new and old branch, then diff them

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CACPiFCJsMK0oOMOZH6WcL27VDk3At3Dz8Pp1Q2o27zPv%2BsmvaQ%40mail.gmail.com.