When you are debugging catalog compilation issues or other puppet performance issues in general, it is good to know exactly which catalogs are slow to compile. Knowing which catalogs are substantially slower than others allows you to focus on those catalogs and the modules they contain.
I was reviewing some pull requests at work today. One of the PR’s had an updated composer.lock file. We usually check if the reference matches the version for this update, to see if that commit is actually released on the module’s master branch:
Usually, this reference matches the hash of the commit we’ve tagged as this version. In this particular case however, the hash mentioned in reference was nowhere to be found in the commit log. So what’s going on here?
I’ve been using bacula for a couple of months now in conjunction with puppet to
make automated backups of all servers that are managed by puppet.
My bacula setup labels a volume for every job it runs with a unique name:
These volumes are automatically purged once the retention of all files contained on the volume expires (which is
configured per-pool). Due to the unique names however, the volumes cannot
be recycled. The result of this is that the volumes that have been marked as
purged in the catalog remain as-is on the disk. After some time this ultimately
resulted in a full disk, thus halting all backups performed on that pool. Not
good. Not good at all.