Hullo I''m trying to work out the best way to use Puppet to control an existing estate, and then how to refactor the configurations. I''d like to use the appropriate tools where I can (eg taking distros to get consistent sets of packages, package managers for the bulk of deployment). During the adoption phase, I think that I want to identify configuration changes from a standard, known, installation image + kickstart file. The configuration is the details of the changed file contents and other metadata (eg existence, permissions). I can fairly easily identify changes from a standard build (eg find all packages and verifying them all, picking out the failed verifications - I''m not sure how to find those filesystem changes that are not part of any package, but leaving that aside for the moment). As I want to use standard builds, I''m basing the effort on fedora builds (puppet 25.5). What seems to me much harder is how to produce a manifest that can reliably reproduce the existing systems, and demonstrate the reliability of the manifest, for more than a couple of machines. I think that I need to do something like: 1- clone the filesystem of each host that needs to be put under control 2- find the files to put under puppet control (ie those filesystem changes that are not the result of the kickstart and subsequent update processes). 3- build a manifest for the changed files (I tried ralsh file for this and came seriously unstuck :-( ) 4- create a test VM and run the manifest against it 5- produce automated comparisons between the filesystem on the VM and the cloned filesystem from step 1: this comparison must be able to handle issues like ''the contents of file x should match the cloned contents, except where this IP1 address is present, when IP2 should be used.'' This feels quite heavyweight, but when I tried a much lighterweight approach of running smaller parts of manifests I was finding that I''d need to clone the filesystem in any case, otherwise I couldn''t identify any changes that Puppet had made, (nor revert back!!) Have I over-egged this? Are there any simpler approaches that I should try - I considered starting from scratch, but it''s non-trivial identifying all of the IT services that are set up, let alone reproducing their behaviour from scratch? cheers Tim -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Nikolay Sturm
2011-Jun-01 11:24 UTC
Re: [Puppet Users] Puppet testing and adoption strategies
* Tim Coote [2011-06-01]:> I''m trying to work out the best way to use Puppet to control an > existing estate, and then how to refactor the configurations. I''d likeI don''t believe there to be a best way, it depends on your situation. When I introduced puppet at our company, I chose to start from scratch and migrate services to the new architecture one-by-one. This is still a huge undertaking, but having installed each machine from scratch with puppet gives us some certainty about configuration coverage, i.e. no files outside puppet''s control. In a different setup it might just be good enough to migrate files and services under puppet''s control as you go. cheers, Nikolay -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.