On 4/3/14, 10:23 AM, Sven Sporer wrote: > 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 > <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 >
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 -- 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/533D3289.7040200%40garretthoneycutt.com. For more options, visit https://groups.google.com/d/optout.
