ewtroan (![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small} ewtroan) wrote,@ 2009-04-16 18:36:00 |
|
A version to rule them all
I've been working on Conary for a long time now. For those who don't know, Conary is basically a version control system for deployed systems. We all use Subversion or whatever for our sources (and probably anything else that looks like source if you squint the slightest bit) for years now, but for some reason we don't use them for deployed systems.
At best, we use a loose collection of versions. Tools like dpkg and rpm (and apt and yum) have integrated the versions of software components into peoples minds pretty well. Questions like "which version of vi are you running" are easy to answer in the Linux world. Simple commands like "rpm -qp /bin/vi" will give you reasonable answers.
What that leaves is systems defined by, oh, 500 versions or so. Oh, and those versions probably don't include version information for your actual application or third party software products. Add those to the count.
What all this means is that those 10,000 servers you're running don't have a version each, they have 500 versions each. You can't go look at two of them and easily see if they're the same. You can't make two of them match without going through backflips. You can't ask what version a server was running last week because the question doesn't make sense; you have to ask what 500 versions it was running last week. It's like using RCS to manage all of your source files. You might get a tag to get some kind of consistency, but aren't git versions better? Finally a single version to describe the state of your source tree. A single way ("hg parent" in my world) to know what the heck is there.
Conary provides the same capability to running systems. Define your systems as Conary groups and have a single version. You need another system like that one? Just install the same version of the same group? You want to know what it was running last week? Look at what version of the group was on there last week (the rollback stack or /var/log/conary will both tell you). Do you need to downgrade? No problem.
I simply don't know how system management can scale without a version associated with a system. Not a piece of a system, but the entire system.
I've been working on Conary for a long time now. For those who don't know, Conary is basically a version control system for deployed systems. We all use Subversion or whatever for our sources (and probably anything else that looks like source if you squint the slightest bit) for years now, but for some reason we don't use them for deployed systems.
At best, we use a loose collection of versions. Tools like dpkg and rpm (and apt and yum) have integrated the versions of software components into peoples minds pretty well. Questions like "which version of vi are you running" are easy to answer in the Linux world. Simple commands like "rpm -qp /bin/vi" will give you reasonable answers.
What that leaves is systems defined by, oh, 500 versions or so. Oh, and those versions probably don't include version information for your actual application or third party software products. Add those to the count.
What all this means is that those 10,000 servers you're running don't have a version each, they have 500 versions each. You can't go look at two of them and easily see if they're the same. You can't make two of them match without going through backflips. You can't ask what version a server was running last week because the question doesn't make sense; you have to ask what 500 versions it was running last week. It's like using RCS to manage all of your source files. You might get a tag to get some kind of consistency, but aren't git versions better? Finally a single version to describe the state of your source tree. A single way ("hg parent" in my world) to know what the heck is there.
Conary provides the same capability to running systems. Define your systems as Conary groups and have a single version. You need another system like that one? Just install the same version of the same group? You want to know what it was running last week? Look at what version of the group was on there last week (the rollback stack or /var/log/conary will both tell you). Do you need to downgrade? No problem.
I simply don't know how system management can scale without a version associated with a system. Not a piece of a system, but the entire system.
