Everything is a Freaking DNS problem

One of the open sessions last week (corr: last month) at Devopsdays 2010 Hamburg was the one on packaging software. It's always a big question on wether you package the software that runs in your infrastructure or not. And if you package it .. what do you package ..

The general consensus of the open space was pretty much that you always package the software you deploy, unless you have some very good reasons not to. Pretty much the way I've been doing for ages ..

Good reasons that were mentionned were the use of scripting languages that update extremely frequently, but certainly not for compiled code, compiling code on a production machine also is a big nono.

There also was a consensus that you DO NOT PUT CONFIGURATION inside a package. You can put in default templates, but you don't put in config files that should change frequently .. There's plenty of configuration mgmt systems out there do that kind of stuff for you.

The naysayers claimed that packaging brings way to much overhead ... and others claim it takes to much time... however I feel it
should just be a 1 time effort that brings devs and ops closer to eachother and from there on it should automated
New versions of software don't mean that the packaging effort needs to be done again..

Another topic that gathered lots of questions was if you should be capable of installing multiple versions of the same package , lots of people mentionned they didn't like fiddling with symlinks however the best comment in that discussion was that there is already a system out there , the alternatives setup .. provide by most operating systems that allow you to do so in a pretty clean way. I must admit I should look into alternatives more in depth too ..

The ever recurring question is wether one should package war files ? Sure as you then can also use the dependency models a package mgmt system brings to deploy the dependent libraries.

However when people ship products, rather than a live service they seem to package everything , mainly because the code in the product isn't changing as quickly as a live website, or internally used application.

The biggest problem however is the frustration people have with GEM or CPAN packages .. they add yet another layer of management to a system, most lots of CPAN packages are already packaged.. but when it comes to GEM's disaster strikes. There's a lot of work left for distributions to integrate GEM and CPAN style packages.

Over at the OPenARK blog Shlomi Noach argues that using apt-get or yum to install your MySQL instance will one day most likeley break your MySQL setup. Depdendencies, distros not shipping the MySQL version you want to use and on some distro's indeed the mysql vs MySQL issue, agreed, it all makes things less trivial.

However why give up a clean packaged system if there are other ways out ?

First of all by claiming that such an installation can break a working production environment looks to me like admitting you don't have a split development, production environment and that rather than testing stuff upfront indeed you just hack a long in production.

So rather than using a tarball for the MySQL instance an --force to satisfy the missing dependencies (hence also cluttering your system) , a much cleaner and less error prone setup is to only deploy from your own , self controlled repository , in which you only allow tested packages, most probably not the distro based package , hence packages that won't break your setups ;) But still you will be using apt or yum and deploying rpm's and debs , perfectly satisfying dependency needs.

Apart from that .. watch out for Banquise .. :) Coming to your favourite distro soon..

So while upgrading python from a limited local repository I broke yum

[root@NTC-BASE-2 ~]# yum -y install foo
Traceback (most recent call last):
  File "/usr/bin/yum", line 28, in ?
    import yummain
ImportError: No module named yummain
<code>
 
However apt was still working
<code>
[root@NTC-BASE-2 ~]# rpm -e yum
[root@NTC-BASE-2 sources.list.d]# apt-get update
STUFF CUT
Fetched 3980kB in 8s (478kB/s)
Reading Package Lists... Done
Building Dependency Tree... Done
[root@NTC-BASE-2 sources.list.d]# apt-get install yum
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
  yum-metadata-parser
The following NEW packages will be installed:
  yum yum-metadata-parser
0 upgraded, 2 newly installed, 0 removed and 234 not upgraded.
Need to get 419kB of archives.
After unpacking 1412kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 <a href="http://mirror.centos.org" title="http://mirror.centos.org">http://mirror.centos.org</a> centos/4/apt/i386/os yum-metadata-parser 1.0-8.el4.centos [24.0kB]
Get:2 <a href="http://mirror.centos.org" title="http://mirror.centos.org">http://mirror.centos.org</a> centos/4/apt/i386/os yum 2.4.3-4.el4.centos [395kB]
Fetched 419kB in 1s (417kB/s)
Committing changes...
Preparing...                ########################################### [100%]
   1:yum-metadata-parser    ########################################### [ 50%]
   2:yum                    ########################################### [100%]
Done.
[root@NTC-BASE-2 sources.list.d]# y
[root@NTC-BASE-2 sources.list.d]# yum update
Setting up Update Process
Setting up repositories

Back in business :)

Good idea Raskas :)

So Russel is wondering how to figure out what platform you are on by adding a script or so that will tell you you are on a RPM based machine when trying to run dpkg or tell you you need to use rpm.

Imvho that system is broken .. as everybody with some brains uses apt, even on an rpm based system.