On Tuesday, January 7, 2014 5:19:42 PM UTC-6, Salient Digital wrote: > > I'm new here, and to Puppet also. > > I've inherited some Puppet 2x code in an SVN repo at my work, and have the > daunting task of sorting out whether we can/should use "what we have", or > if we should upgrade/rewrite everything from scratch on Puppet 3x. > Obviously there are pros and cons of each approach. We have to manage about > 40 servers with the setup. > > *Are there any dead giveaways to tell what version of Puppet this code was > written for?* > In analyzing the puppet code that I have access to, it appears it was > built for Puppet 2.6 or 2.7 but I can't tell for sure. (Of course code > comments would be great if there were any.) Does it matter? >
The easiest thing to do would be to look at what version of Puppet the code is already being used with, but I suppose you wouldn't be asking if that were possible. You can get an upper bound on the target version by looking at files' SVN timestamps. Puppet has gone from version 0.24.x to 3.4.x in under five years (with 0.25 being the predecessor of 2.6), so the timestamps can give a relatively fine-grained indication. If your code uses parameterized classes then it is targeted at 2.6.x or later. Overall, though, DSL code is fairly portable from one version of Puppet to another, so there are no real distinguishing characteristics to tie code to one specific Puppet version. > > *Anyone have any good puppet 2x to 3x upgrade guides/notes/links?* > What would be killer is a complete list of changes and example code like > if you did it this way in Puppet 2x then this is how you do that in Puppet > 3x. Wishful thinking maybe. > > Best strategy: get your code running under 2.7.latest, resolve all warnings, then move up to 3.latest and fix what breaks (if anything). One of the key objectives of 2.7 was to help people prepare for 3.x. > *Do any meta-data upgrade tools exist?* > I have a lot of /extdata/ folders containing CSVs. I assume that this > should be re-done with Heira for Puppet 3.4. I've read the Puppet 3x > upgrade docs and lots of blog posts about upgrading puppet, but it doesn't > mention much about upgrading your own Puppet code and data sources. > > The extlookup() function still exists in Puppet 3.4, so it is not essential to convert your manifests or data right away. With that said, hiera is all-around better than extlookup, and Puppet 3's automated data binding feature relies on it, so you are likely to want to switch. It should be possible to write a CSV backend for hiera (in the unlikely event that none is yet available), and that would ease your transition by allowing you to convert your manifests completely to hiera up front, while transitioning your data over time. > *Should I start from scratch?* > I see here that the puppet code I'm looking at was built by hand for SLES > & Zypper with a custom RPM (I don't have access to) and we're using a > different OS now. (CentOS mainly), so I'm not sure there's really any value > to "what we have" beyond study as example code of how things used to be > done. > > That's a fair question, but only you can truly answer it. Given the amount of uncertainty surrounding your legacy Puppet code, however, I am inclined to suspect that you would indeed be better off starting from scratch. By all means do keep the old code and data around, though -- beyond their value as an example, they may contain valuable information somewhere within. > *How do I tell what files, services, packages are managed by Puppet?* > I've found a few tools that scan puppet code to find resources (files) > managed by puppet, but I'd also like to know which packages, services, > users and ssh keys are managed by puppet. This is on a VM we have running > Puppet 2.6. Suggestions here would be very helpful. > > Packages, services, etc. managed by Puppet are also "resources" in Puppet terminology, so do the tools you have found (which?) actually identify only File resources, or do they perhaps already do what you are asking? Given that you say you have "a VM" running Puppet (as in a single machine), it must either serve as its own Puppet master, or else it must use "puppet apply" instead of "puppet agent". Either agent/master or apply is ok, but you should be sure you know which, and you should have an informed plan for which approach to move forward with. In any case, you should be able to process the compiled YAML catalog, recorded in a file on the target machine, to identify all managed resources. I don't have a specific tool to recommend to you; for a one-off, it is possible to do it by hand. Of course, that tells you only about that particular node. You can manually compile catalogs for other specific nodes, too, and examine the results, but to reliably find all resources that might possibly be managed on *any* node, based on a given manifest set and data, there is no good alternative to manually analyzing the manifests and data. John -- 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/1857b060-8b49-47a6-9fdd-15bed8648099%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
