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 <s...@intothespirit.com> 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 puppet-users+unsubscr...@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<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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CA%2B0t2LzxDZ2VVhKNgAfBC19gDEOHqiNJD%2BVLrC%2Byx2vsp1KSOA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
