This is slightly off topic, but since I think this is a problem nearly
all RT administrators face I am looking for advice/suggestions.
I like to use kickstart to build RHEL systems and I’m sure other people
use automated build processes as well.
What is incredibly difficult is satisfying all the perl module
dependencies. Right now I build RPMs for all the perl modules using
cpan2rpm or pull down some RPMs from the Dag Wieers repo. This takes a
long time and with each RT version upgrade, I need even more perl modules.
I’m hesitant to install from CPAN as part of the automated build process
because versions change, and if a server goes down or something else
changes I don’t want to have it affect my automated server build. Plus I
want consistant versions. If I rebuild the machine today, or a year from
now, I want the same version of various modules working.
So what do you all do? I want to build the machine in a reproducible
way, so just installing the modules using cpan today isn’t going to work.
This is slightly off topic, but since I think this is a problem nearly
all RT administrators face I am looking for advice/suggestions.
I like to use kickstart to build RHEL systems and I’m sure other
people
use automated build processes as well.
What is incredibly difficult is satisfying all the perl module
dependencies. Right now I build RPMs for all the perl modules using
cpan2rpm or pull down some RPMs from the Dag Wieers repo. This takes a
long time and with each RT version upgrade, I need even more perl
modules.
In an ideal world, I’d do what you’re suggesting, and store those
RPM’s in my own repository. In fact, I use Debian, not Red Hat, but
the principle is the same. It’s particularly awkward at the moment,
though, because the new version of RT requires versions of some of
these perl modules which are considerably more recent than those in
Debian stable, so for testing purposes I’ve gone for the CPAN
approach. It does mean that things could go wrong with a future CPAN
update, but I don’t tend to upgrade RT frequently (this is my first
upgrade since RT 3.4.2)
Tim
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
There is one person here who feels very strongly about the RPM based
approach (not me) but I do agree that RT doesn’t really get rebuilt very
often. Since we actually run it in a VM on top of ESX, I almost feel
like the kickstart isn’t as necessary as I can make copies of the VM
files and feel reasonably comfortable that way. Kickstart is awful nice
when dealing with bare metal and being able to restore.
However I have restored exactly…never. So I’m not sure which way to go.
Here I am looking at going from 3.6.x to 3.8 and it basically involves
building a whole new machine. I can’t imagine actually upgrading it in
place based on everything that has to be installed.
I’m curious what the RT people do to manage all the perl modules in a
consistent way since I’m sure they build a ton of test machines over and
over again.
There is one person here who feels very strongly about the RPM based
approach (not me) but I do agree that RT doesn’t really get rebuilt very
often. Since we actually run it in a VM on top of ESX, I almost feel
like the kickstart isn’t as necessary as I can make copies of the VM
files and feel reasonably comfortable that way. Kickstart is awful nice
when dealing with bare metal and being able to restore.
However I have restored exactly…never. So I’m not sure which way to go.
Here I am looking at going from 3.6.x to 3.8 and it basically involves
building a whole new machine. I can’t imagine actually upgrading it in
place based on everything that has to be installed.
I initally set up our RT instance on a FreeBSD machine. It was pretty
damn easy, took me like 10 minutes. Most of our production network is
run on CentOS 5, however.
Late last year I set up a completely new kickstart environment which
allowed us to fully automate 90-95% of the roll out process here. I was
interested in setting up a new RT machine, as the one it’s currently on
is pretty old.
However, the sheer amount of work required to ensure the Perl module
RPMs are of a sufficient version and stored in my local yum repo was
enough that I spent multiple days downloading and building the RPMs. I
later found cpan2rpm, which did help. Then I realized that the “set it
and forget it” (thanks, Ronco) method I used was, in this single
occasion, a much more efficient use of my resources to the company.
We’re not rolling out 20 new RT instances every week.
Since I set it up last September, I’ve upgraded RT three times on that
machine and all it really required was ensuring my ports tree was up to
date before trying to upgrade the Perl modules.
A week or two ago I posted asking about how people deal with CPAN
modules when using an automated process to build RT machines, and it got
me wondering, how does the Best Practical crew do it?
I imagine while testing you guys put up and take down hundreds of RT
machines.
What is your build process? What OS do you run RT on? What tools do you
use, etc?