The resurrection of autoinst ...

A long time ago, in a galaxy far, far away … I worked for this company named SGI. SGI machines and software were awesome … I had used them (R3k and R8k) for doing calculations for my thesis. Very very fast. But very hard to install/manage. In fact, brutally hard. This was not lost on customers with many of these devices. One of those customers read SGI the riot act on this. They gave SGI an ultimatum to make the install and maintenance of these machines as easy as the Sun machines were (via jumpstart), or they wouldn’t buy more machines. As they bought quite a few machines, this had some impact. My management asked me to look into the problem and come up with a solution. I thought this was strange as I was in the field, and most of the development resources were in Mountain View. But I got started. And ran head first into a force of nature within the company, whom was adamantly … vociferously … opposed to the concept of what we needed to do. So I had to work around him. With effectively zero support from the rest of engineering … hell … more honestly … outright antipathy … we developed autoinst. It worked by booting a machine diskless, and then doing very … very naughty things to the disks in order to install or update the OS. Turns out, that we could also set it up to run the same command across thousands of machines as well, by telling it not to reboot. I wrote it all in Perl. Documentation was in LaTeX (not kidding). It made the customer very happy. It was actually easier to use than jumpstart. It worked. Though we ran into a few people who couldn’t imagine anyone but Sun coming up with good things, it was widely praised by users. Eventually engineering gave in and developed Roboinst. Can’t have them thar field folks doing stuff like this … Ok, back to autoinst. I started out in a “hackish” manner with it, but eventually developed it into a very robust installation and management platform. It could do things no other platform could at the time. Even today, Chef and Puppet are, to a degree, quite a bit behind what we’d managed to do. They handle things post install. We completely controlled the installation, and handled the post installation with the finishing scripts … which eventually started to evolve into what we use today. Awesome power, very repeatable. Very unix-like (do one thing, very well, play well with others). Why all of this? Because I am sick and tired of positively borked installs using distro X’s preferred mechanism, that doesn’t actually allow me to configure what I want to do, the way I want to do it. I want my disks arranged in a very particular way, but the only way to handle this in anaconda|yast|d-i|… is to write something that these installers escape to (e.g. external to the installers). The only way to guarantee that grub is correctly installed (yes, you do have to worry about that) is to do it by hand, post installation. None of the distro installers will use our kernel (baaaad, very very baaaad). None of them will allow me to configure the networking, or other elements without escaping from their installer. So … and this was the reasoning that led me to autoinst … why bother using their installer? I can handle all of the tasks, completely programmatically, far better than the installers can. The package managers are generally smart enough to allow you to install most of what you need, apart from fixups. So why, again, would I want to leverage something that doesn’t work, and shoehorn it into something that does? So I am thinking its time to resurrect the concept. Scalable OS (aka Tiburon) handles all the booting issues beautifully. I’ve wasted enough time on other peoples broken code, that I can’t fix, as the code base is often insanely complex. Which might be why its broken.