Everything is a Freaking DNS problem

I must be so out of IBM's target audience with regard to their Drupal Hosting article Dries pointed us to.

Lemme say that again, I was probably not their target audience ! so my opinion on the article isn't really relevant. But still, here's what bothers me in the article.

The article explains how to create a virtual machine with Drupal and how to deploy it later in a webhosting infrastructure. A very good idea, however the way they explain the user how to do it will lead to problems when one eventually wants to scale further. Some basic rules of Large Scale deployment have been forgotten (but as told that was not the audience). Nowhere in the article is reproducability or scalability mentionned.

Early in the article I read that they were disappointed they couldn't use Xen because the management tools were not as polished and robust as they would like.
They couldn't save enough time by using Xen but had enough time to create a zillion screenshots from a gui ? For me managability means that I can script everything and I don't need a GUI. Actually having to use a gui to configure stuff means it's NOT manageable at all. Certainly when going to Large Scale installs. Imaging having to click 100 times on a start button, that just doesn't scale.

But not all is bad in the article Using LVM is good , very good, Using CVS good & taggin good , checking out CVS from the production server, not really good .
As long as you have 1 server it's fine, but as soon as you have more servers you will one day have a developer fixing a bug on machine 1 , even comitting it, but it never gets deployed to machine 2,3 and 4. So it's a good habit not to allow it for starters as old habits die hard :)

One should have a mechanism in place that pushes new updates to the servers, or have the servers periodically pull the update, which brings me to another topic, should I package parsable code , or should I keep the files in a repository file by file and have method to transfer those. Hmm.. that's stuff for a different posting.

Next up is a really bad habit. It's all the dissadvantages of transferring full disk image vs recreating that same image in a different machine. It's the VMWare idea of deploying, just copy a big file to another disk and start the virtual machine there. Good, for testing, demos etc.. but not for large scale deployment Use real LVM on the machine and deploy there , reproducable.
The biggest problem with transferring disk is that you never now how you got there , and you'll never be able to reproduce what you did .
My paper on Automating Virtual Machine Deployment explains how you can do this, mind the methodology, not the tools.
It doesn't matter if you use Fai, Kickstart or SystemImager , but USE them !

This article is a a good start for developers, but it's a No Go for an experienced system admin. Working like this just doesn't scale.