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. Am Mittwoch, 2. April 2014 20:59:31 UTC+2 schrieb 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. > > > On Wed, Apr 2, 2014 at 8:32 AM, Sven Sporer > <[email protected]<javascript:> > > wrote: > >> 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 >> >> -- >> 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] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-users/0d485460-fefe-43df-b060-cd769818a643%40googlegroups.com<https://groups.google.com/d/msgid/puppet-users/0d485460-fefe-43df-b060-cd769818a643%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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/81b9e8a2-3150-4f2d-9e97-c5c7e25d032f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
