On 05/09/2016 04:12 AM, christg76 wrote: > Thanks to everyone for the comments! I think I first need to do some > preliminary testing in order to assess the quality of the code and to > see what the real challenges are, and to ultimately decide on a > strategy, ie upgrade vs transition/migration. > Ramin K: OS of the Master is Debian Wheezy. Have you actually done the > upgrade? > Andrew Grimberg: This approach in fact sounds as if its the best way, > considering also what Henrik says below about new > versions/modules/tooling/practices. But it sounds like a massive amount > of work, particularly since we do not have any unit tests or similar in > place. Did you have any unit tests in place with the old code, or if not > are you implementing them with the new code?
Chris, Our old code base had no unit testing built in. That was one of the that I, as our puppet architect, require of all the modules that we use. The only exception (and this is mostly due to lack of some internal tooling) is our roles / profiles modules. If you're interested in our puppet layout I can't give you a link to our current configuration (as much as I want and we'll eventually have it available) but I _can_ give you a link to all the repositories I use for my private servers and personal puppet lab :) I have a from nothing to fully running article that I really need to write utilizing these at some point. That being said here's the design what you can see in how I (and by extension the company I work for) utilize: Master puppet repo: https://github.com/tykeal/puppetserver-main hiera: https://github.com/tykeal/puppetserver-hiera role module: https://github.com/tykeal/puppetserver-mod-role profile module: https://github.com/tykeal/puppetserver-mod-profile local_fw module: https://github.com/tykeal/puppetserver-mod-local_fw.git Yes, that really is the hiera module that I use. I'm not concerned about having it visible because I use the hiera-eyaml-gpg backend and all the truly secure information is GPG encrypted, anything not encrypted isn't all that useful. Yes, it would help someone map how my environment goes together but you would have to be able to get in first and if you can do that a lot of stuff ends up in the clear anyway ;) The Puppetfile in the master repo details every single module I presently have in my testing environments. You'll notice most are just pinned to Forge versions, some are pinned to github checkouts for various reasons. I'll also note that in some cases, there are modules that are being installed that I don't actually use (gentoo/portage for instance), they're only there so I don't get the annoying warning displays of unmet dependencies if I do a 'puppet module list' on the puppet master ;) The profile, role and local_fw modules are not pinned to a specific checkout because it is expected that the puppet master should always be at the lastest version of those and it gets to that state after every puppet run as there is a post run job defined for the puppetmaster itself that forces an r10k run to happen. I had initially tried it as a pre-puppet run but always ran into some weird issues with it that way. -Andy- -- 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/5730A52D.4090703%40bardicgrove.org. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
