Managing big changes

[Sven Sporer]

Hi,

I'm wondering if there's an established way on how to write and improve modules with potentially system-breaking or incompatible changes. One example are changes in the filesystem layout, or simply the change of an OS user's homedir (usermod fails because of running processes).

Of course, Puppet isn't at fault here, but the question is: How do you write a module to support this? It's not always possible to just bootstrap the server again (=> potential downtime), or breaking Puppet runs until there's time to manually prepare the server for changes.

We could use multiple environments and Puppetfile's (r10k). On the other hand, this means that there are a lot of environments to manage (deploy module updates, ...).

Any other angles (or posts somewhere) on this?

Sven

[Dan Bode]

Hi,

A couple of things that I have tried before.

1. If the intention is to perform a refactor where the code changes are large, but the expected changes to the catalog are small, I would recommend looking at:

  - https://github.com/ripienaar/puppet-catalog-diff

Depending on what versions of Puppet you are looking at, you may have to hack on it a bit.

2. Environments are useful for detecting potential changes in combination with --noop. You should be able to target an agent to your new environment (containing the changed code)

    puppet agent -td --environment new_env --noop

And verify the impact of changes before you make any changes.

The main problem with environment is that they do not work correctly with types and providers.

3. Although the cost of writing and maintaining rspec-puppet (ie: unit tests) can be quite high. Refactors are where they really shine. If you have good test coverage, then after a refactor, you should be able to see what expectations you have broken and have to update your tests accordingly.

--
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/0d485460-fefe-43df-b060-cd769818a643%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sven Sporer]

Thanks Dan, I didn't know about puppet-catallog-diff. I'm already using rspec-puppet to test the module logic, and extensively use VMs to test the bootstrap of new systems. I don't fear that I will introduce bugs in my modules.

The issue I had in mind is more of an issue with managing your module versions, due to changed requirements, I'm now forced to introduce changes to the module which prevents successful Puppet runs on old/existing servers. One example I had is the switch from ext4 to xfs. This change is on purpose, I know Puppet can't magically deal with that, and if I want to keep servers updated, I have to make sure this change (but changes of other modules!) won't be applied. At least until I made sure it'll work again, which depends on the type of change.

These are situations where the drift management capabilities of Puppet can't help me. I guess I need to start managing separate environments, each with their own set of module versions.

[Garrett Honeycutt]

Hi,

Dan's tool, librarian-puppet-simple[1], can help with this in
conjunction with environments. You specify a Puppetfile that lists all
your modules and their versions. This file can then be stored in
revision control and you can use different versions of the Puppetfile
for your different environments. Here's an example[2] of my repo for
managing this.

[1] - https://github.com/bodepd/librarian-puppet-simple
[2] - https://github.com/ghoneycutt/puppet-modules

Br,
-g

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