Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Finally! Saying goodbye to perl 5.005

by the_slycer (Chaplain)
on May 05, 2005 at 15:09 UTC ( #454396=perlquestion: print w/replies, xml ) Need Help??

the_slycer has asked for the wisdom of the Perl Monks concerning the following question:

Hello monks

I (and others) have finally convinced the PHB's that moving our legacy perl 5.005 system, running in production on machines that nobody knows how to rebuild (short of mirroring the drive), on Redhat 6.2, using an ancient version of apache & mod_perl, would be a good thing.

It might be nice to have development machines that are running the same version as test, which could be running the same version as production.. go figure.

Because I was vocal about this (we have been bit a few times by stuff passing test, but failing on production due to module versions - don't even get me started on use warnings failing...), I get to run with the project.

I am aware of some of the problems, for example, not having the LANG environment variable set to sane things causes wierd errors in perl 5.8.0 that were never there in 5.005, but I also have never had the opportunity to handle a migration before.

What kinds of things am I going to have to watch out for? Has anybody been through an upgrade like this? We use mod perl with apache 1, the new machines have apache 2 by default, should we revert to apache 1? What kinds of things might we get bit by with apache2/mod_perl2 vs apach1/mod_perl1.

Just an FYI, we have upwards of 200k lines of source code, and no regression testing built around the system, so I can't just put it on and see what works, I'd like to get an idea of problem spots that I'll need to look at.

Any suggestions would be welcome!

update: Ok, advice taken, no mod_perl_2 will be the plan. Any other gotchas moving from 5.005 to 5.8.0?

Replies are listed 'Best First'.
Re: Finally! Saying goodbye to perl 5.005
by dragonchild (Archbishop) on May 05, 2005 at 17:40 UTC
    You will have to recompile every single module you're using as 5.005 and 5.8 are not binary compatible. In addition, some Perl modules will modify themselves depending on the installing Perl version.

    These are the steps I see, in order:

    1. Get your boss's buyin that this will be a 6-month process.
    2. Get your code into source control. Subversion is probably best, here. This is non-negotiable failure point.
    3. Get some sort of one-step deployment/build process. This may involve adding configuration files, writing scripts, and the like. This is non-negotiable failure point.
    4. Get a machine that you and only you control. Since you're running Linux, converting your desktop should be plenty powerful. The goal is isolation, not power. (I did this at my last job and my desktop was the production webserver/dbserver for a few months.) Ideally, not even the sysadmin has root on your box. This is a non-negotiable failure point.
    5. Build your ideal system on your isolated machine. Once you have it built (Perl / DBD modules / apache / mod_perl / mod_ssl / database / etc), take a snapshot. Ghost is good for this, but any backup/restore will do. Remember - you have to deploy this configuration a few times. You will want to be able to do this without having to remember to install foo before bar but after floober. This is non-negotiable failure point.
    6. Write down a series of acceptance tests. Focus on the critical systems. For example, if you were developing Quicken, you'd start your tests with the lineitem entry stuff and worry about the pretty graphs later.

    Note - none of the above have anything to do with Perl, specifically. They're good practices for any kind of major infrastructure upgrade.

    Oh - those failure points? If you don't do them, you fail. Period.

    Once you have done all that (about 3-6 weeks work), then you can start the actual work of migrating your codebase from 5.005 to 5.8.x by doing a build from source control to your isolated box, then running your acceptance tests against it.

    Have fun - this is a wonderful project that will give you amazing kudos when you get it done.


    • In general, if you think something isn't in Perl, try it out, because it usually is. :-)
    • "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
      Build your ideal system on your isolated machine. Once you have it built (Perl / DBD modules / apache / mod_perl / mod_ssl / database / etc), take a snapshot. Ghost is good for this, but any backup/restore will do.

      I strongly agree with most of your points, but taking snapshots is a very effective way to be in the same boat a few years down the road when you have to do the migration again. Especially if your starting point involves cloning a developer desktop machine. You might as well be doing brain surgery in a crack house!

      I've been down the system cloning road and here's what I do to avoid it:

      The thing you want to do, while you're building your ideal system, is to document the living daylights out of the setup process and automate as many steps as possible. For example, rather than documenting all 50 CPAN modules you need to install, create a new module with all the dependencies already mapped out (Makefile.PL's PM_PREREQ, for example). Installing it should suck in everything else you need. Put your web server configurations into your SCM.

      The final goal is that a literate monkey can take bare metal and some CD-ROMs and just build your ideal system from scratch in a few hours. Repeatedly. And if it's not the identical O/S with the identical version of perl, apache, etc, having a repeatable process should work around all the little details like binary compatibility and whatnot. As long as it passes the acceptance tests. That's a non-negotiable failure point.

      c.

        The idea is to reprovision a developer desktop into what a production server should look like. Then, take a snapshot. I agree with you completely that you should also be able to build any server in your network using a literate monkey, bare metal, a T1, and some CD-ROMs. But, that doesn't mean you can't have both.

        • In general, if you think something isn't in Perl, try it out, because it usually is. :-)
        • "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
      Thanks for the comments.

      We are using cvs, so that will be the source control tool, and we'll be creating a new branch for any development that needs to occur for the change to be succesful.

      The acceptance tests are a bitch, but I'll give it the best go that I can, just some background, I came into this company a year ago, we're slowly moving everything to java from perl, but it's a slow enough process that we can no longer put off upgrading perl.

      The code is quite simply some of the most horrible code that I've seen, the guys that started this system off did not know perl very well at all, worse, they didn't know how to program (we've got 8000+ line INLINE scripts - no subs)

      In addition, nothings documented, some of the code is stuff that just runs, hasn't been looked at forever, and nobody really knows what it's supposed to do. It's a major headache just trying to maintain the stuff, it would be good to get some tests written during this migration to help with the maintenance afterwards...

      It should be a good time, and I do have the buy in for the timeframes, machine, etc..
        slowly moving everything to java from perl

        If you really are moving everything from perl to java, I'm not surprised that things are going slowly.

        nothings documented, some of the code is stuff that just runs, hasn't been looked at forever, and nobody really knows what it's supposed to do.

        Read "Perl Medic".

        I would argue then that building the acceptance tests is a non-negotiable failure point. You know what the heck is going on or you fail. *shrugs*

        • In general, if you think something isn't in Perl, try it out, because it usually is. :-)
        • "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
      Every so often I desperately wish I could vote a node up, like, 5 or 10 times instead of just once.
Re: Finally! Saying goodbye to perl 5.005
by cbrandtbuffalo (Deacon) on May 05, 2005 at 17:38 UTC
    We're getting ready to go from 5.6.1 to 5.8.6, so I'm dealing with some of the same issues. I posted a while back for some initial guidance in the node: Maintaining an Enterprise Perl Distribution. I plan to post more detail on what we did and how it went after we convert. We're probably going to start the actual work in June.

    We're also looking at Apache 2 and mod_perl 2, but I agree with the suggestions to limit how much you change at once. On that note, you may want to consider re-installing only the modules you really use. Monks provided some guidance on that in this node: What modules are we actually using?.

    Good luck!

Re: Finally! Saying goodbye to perl 5.005
by perrin (Chancellor) on May 05, 2005 at 16:00 UTC
    200K lines of code with no tests? Stick with mod_perl 1. It doesn't even matter what the differences are.
Re: Finally! Saying goodbye to perl 5.005
by adrianh (Chancellor) on May 05, 2005 at 16:14 UTC

    Just an FYI, we have upwards of 200k lines of source code, and no regression testing built around the system, so I can't just put it on and see what works, I'd like to get an idea of problem spots that I'll need to look at.

    Any suggestions would be welcome!

    Stick to mod_perl1. Start writing some tests :-)

Re: Finally! Saying goodbye to perl 5.005
by eyepopslikeamosquito (Chancellor) on May 08, 2005 at 04:06 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://454396]
Approved by kutsu
Front-paged by kutsu
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (6)
As of 2020-05-29 12:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    If programming languages were movie genres, Perl would be:















    Results (169 votes). Check out past polls.

    Notices?