OpenCM Alpha6 Released 39
Jonathan S. Shapiro writes: "The new OpenCM Configuration Management system has just released it's first external alpha (0.1.0alpha6) over at opencm.org -- brought to you by the same folks who are working on the EROS operating system. Being a 0.1 alpha release, it shouldn't be used for prime time development yet, but it's definitely ready for a first look. We've been using it internally for OpenCM development for a while, and we have officially moved EROS development over. It looks like most of what needs to be done toward a first release is cosmetic at this point. Alpha6 has been tested on RedHat 7.3. Porting and cleanup are underway for solaris and (soon) *BSD. People seem to be excited about this -- especially the OpenBSD folks. While you are over at the web site, have a look at the two papers on OpenCM from this year's USENIX and USENIX Security conference."
Details, details... (Score:2, Informative)
Re:Details, details... (Score:4, Informative)
"Configuration management" is an industry term for precisely what this product does, which is product revision control, and not source file revision control. You will notice that other tools like AEgis and many commercial tools also refer to themselves as "configuration management" rather than "source control".
What configuration? (Score:2)
It's still a stupid term. Tell me, where is the configuration that is being managed? Industries have lots of meaningless jargon--doesn't mean us sane folks have to parrot it. "Revision control" works just fine and makes sense.
Re:What configuration? (Score:2)
Confusing, maybe, but certainly not stupid. OpenCM, like many other tools, is mistaken as a revision control tool, but isn't.
Revision control systems like RC and CVS are concerned with tracking revisions of files. The have some limited capability to track revisions of entire systems. But the lack the capability to properly track and manage the way a system is put together from its components.
Maybe the easiest way is to think of a system as one of those cool (well, they were then) transformer toys. In its airplain configuration is goes really fast, but change it to its robot configuration and it has laser weapons.
In a software system, configuration management is concerned with which revisions of which files make up a particular "distribution" (for lack of a clearer word). It can also track this information across what would normally be separate projects in revision control systems. In its simplest for, CM can be a text file which says "This is label 1.2.14 of the main system, and is built against label 2.7 of libraryA, which in turn is build against label 0.96 of libraryB". A proper CM system gives you far more flexibility (I am not familiar with OpenCM's capabilities).
What software geeks usually refer to as "configuration" should more often than not be called "preferences". A Linux distribution is a particular configuration of Linux and associated tools, but your installation of that distribution has been specialised with a number of your preferences.
Re:What configuration? (Score:2)
It's more natural for me simly to think of RCS and CVS as semantically limited revision control tools, and ClearCase, subversion, and BitKeeper as more complete and powerful revision control tools. Ie, I acknowledge the fundamental differences between more primitive and more advanced systems, but I reject the notion that they deserve different names.
Maybe the easiest way is to think of a system as one of those cool (well, they were then) transformer toys. In its airplain configuration is goes really fast, but change it to its robot configuration and it has laser weapons.
Yeah, I've thought of that argument, but it's a big stretch. "SCM" systems don't let you use a single codebase as either an airplane or a weapon, at least not the way they are normally used. And even if I let you get away with calling the specification of library versions as "configuration", that is hardly a core feature of these systems.
Face it: the primary purpose of any of these systems is to manage the various versions in some body of content. So I reassert that "version control" or "revision control" or "change control" is the best name.
And by the way, the fact that the name is confusing does matter, especially for a free software project. If you're trying to appeal to developers, its best to pick a name that won't confuse all the students who haven't been corrputed by industry jargon. :-)
Re:What configuration? (Score:2)
You can use a version control tool to keep track of this information, but it is a lot of work and is pretty hard to keep straight (keeping the install scripts in CVS is often confused for a CM solution, but it doesn't help when your old CM guy leaves and you need to bring the new CM guy up to speed on what goes where and why). The real purpose of CM is not simply to make it easy to install and configure the system, but to make it easy for humans to understand what that process entails and detect when something has been changed or overlooked.
Some folks might be forgiven for thinking that CM and version control are the same thing: if you have never worked on a real production system before (one with many programs and a complex set of directories and configuration files, as opposed to some little toy program for a class project) you have probably never encountered the need for CM. Unfortunately, there is almost no way to demonstrate the need for CM in the small: unless the size of the system is larger than what one person can comfortably think about at one time, the need for CM just doesn't arise.
Re:What configuration? (Score:2)
I know about programming "in the large" (or at least medium-sized). I've used tools more powerful than CVS. These tools are powerful because they do version control better than CVS, not because they offer something fundamentally different.
And your argument that CM is about what files go where seems like nonsense to me. First, even if that is important, it hardly requires a sophisticated tool. You might as well use (a subset of) RPM for that. Or a 100 line Perl script (that reads the file locations, etc, from a config file). Second, code should generally be buildable and runnable right in the source control system, for quick testing. So if you need some fancy layer just to get the code into a runnable state, you're probably doing something wrong.
Re:What configuration? (Score:1)
1. Because CVS is a very popular system being used currently for an "80 percent solution" for true configuration management. The user interface to OpenCM could have been designed to any paradigm, but why not use the most widely used (open source) system since a LOT of developers are already familiar with that? BTW, OpenCM only manages configurations, or sets of files. You can't (yet) grab only a single version of a single file unless it's the only member of a configuration. That's the whole point of CM, as previous posts have exhaustively pointed out.
2. Most large free software projects have "gotten away without it" because "it" hasn't been available! Again, one of the best (open source) solutions to true CM out there currently is CVS, and it's only an 80 percent CM solution! Ask _several_ CVS users what they don't like about CVS and you'll have a list of requirements for a true CM system!
3. ClearCase is a marvelous tool. (I'm not an expert at ClearCase, but I've used it.) Unfortunately, it costs more money than I have! However, don't you have to have network access to your ClearCase server (repository) in order to work with it? Wouldn't disconnected development be a wonderful addition? (It doesn't look like OpenCM actually supports that yet, but it sounds like it's in the works.)
Re:What configuration? (Score:2)
Again, my challenge is to evince some important function of "configuration management" tools that is fundamentally different from version control.
Re:What configuration? (Score:1)
You are arguing about lexicon. As I said earlier, the software industry made it's selection here 15 years ago, and it isn't going to change. I understand why you think a new term isn't called for. In fact, I probably agree. That said, arguing about it is kind of like trying to reopen because you don't think the armistice lines were drawn in the right places.
Re:What configuration? (Score:2)
Second, the shortcomings of CVS are not the issue. CVS is a version control tool, not a CM tool.
Third, I've never used ClearCase, so I don't know what features it has that may (or may not) be relevant to CM. However, unless you are the CM guy, it is likely that you never use any of the CM features of ClearCase. As a programmer, you don't really need to do anything other than version control, but that doesn't mean that version control is the only task that is important or that the tool supports.
One final time: CM is all about keeping track of exactly what versions of what files went into a specific build of a system (you may be shipping different builds of the system to different clients, for example), where those files are stored in a specific build, what was done to install the build on the client hardware and what environment variables/registry entries/symbols/logical names/etc. were set to what values for any specific installation. Much of this information can be (and often is) stored in the form of installation and configuration scripts that are kept under revision control. You may also want to associate user documentation, discrepency reports, enhancement requrests, work orders, and even client specifications or contracts with a specific build for a specific client. On top of all this you would like to have the information in a form that can be readily digested by humans (assorted install/configure scripts do not meet this requirement) so that new recruits and non-coders can understand what goes into the system and its installation.
To say that just becuase you have the installtion and configuration scripts in revision control, you are effectively managing the system configuration is like saying that just because you have been given the compiled executables, you have all the documentation you need to maintain and enhance the software! CM is not about the source code, but about the meta-data of the built and installed system. It tells you not only what you can tweak in the system, but also how that tweaking was done for a specific installation.
In summary, CM records the following facets of the system:
Re:What configuration? (Score:2)
That said, I do now have a better appreciation for your view of configuration management. Let me try to fit my experience into that framework. ClearCase (which I do know fairly thoroughly) has some features in this area. For example, it can hook into your build process and remember which source-controlled files contributed to built files. It can give you a "view" onto arbitrary versions of different modules. But bundling up a release, producing a manifest, tracking installations, etc, are generally outside its scope (and are left for tools such as ReleasePro [releng.com]). So by your definition, ClearCase is not a configuration management system.
Re:What configuration? (Score:2)
As for doing something wrong if it takes so much effort to get the code into a runnable state: you are probably correct. The sad fact is, however, that most large software projects are doing something wrong in exactly this way (many somethings, in fact), but there is little hope of being able to turn the tide.
Really large software projects are too big for even a large team of people to tackle every aspect of the system. Therefore, large projects must be built on top of smaller pieces, often pieces that have been built by other people. Each of these component pieces has its own fiobles and requirements, all of which combine to present the system architect with one giant mess of fiobles and requirements. The job of CM is to manage this mess of foibles and requirements in such a way that the system can be installed and operated without bankrupting the company in the process.
Re:What configuration? (Score:1)
CVS uses various tricks to straddle the boundary between revision control and configuration management. Features like "tags" are an approximation to configurations. There are things we need that CVS doesn't (and can't) do, like rename, but CVS is presently the best available tool (or it was two weeks ago :-)
We describe OpenCM as a replacement to CVS because the command interfaces are intentionally similar and because most of the target users of OpenCM are currently using CVS.
CM isn't needed for programming in the large. It's only easiest to see there. CM starts to be needed the minute your program is spread across more than one file and you might need to recover older versions. The missing piece in RCS is that it does not know how versions relate between one file and the next.
If you are managing sets of versions of files, instead of versions of a single file, then you are doing configuration management. I understand why you don't want to give a separate name to configuration management, but the naming debate ended in the SCM industry almost 15 years ago. Arguing about it now is pointless.
SCM isn't about what files go where. That's system CM. SCM is about which versions of which files go together to build a particular application version.
Re:What configuration? (Score:2)
Ok, I'll relent and accept that as the defining characteristic of configuration management. At least it is a clear criterion that is stronger than "version control", and has some amount of sense to it. As opposed to some of the divers definitions offered on this thread.
Even though to me (as I said before), it is just "better version control".
Re:What configuration? (Score:2)
We use a commercial configuration management tool which has no revision control capability.
Pre-release activities include labeling the source code in the various parts of the separate revision control tool and archiving it (.zip or .tar.gz), then putting the code archives, design documentation, hardware diagrams, Bill of Materials, installation programs, user manuals, and an image of the final (distributable) CD into the CM tool.
Every unit of data which is stored in this manner is assigned a unique identifier, which is propegated back to the source of the data (VSS trees are labeled with the source code UID, source code is updated to contain the UID so that it appears in DLL versioninfo, documents have their UIDs added into them, the CD has the UID in a file in root and printed on the label, etc).
Finally, the CM also tracks the development of systems as a whole (hardware, software, documentation in their entirity), as well as delivery to customers. Patches are also entered into the CM separately, and their delivery tracked.
In short, given any program or part thereof, or piece of hardware, documentation, CD, whatever, we can identify all the source code (main application, tools, firmware), design documents, hardware processes, material providers, previously discovered bugs (linked to a separate system), patches available and applied, and so on.
For a commercial environment which values engineering processes, the benefit of this sort of knowledge should be clear. It is also something which can't be done with most revision control tools (notably, it would be possible to do it with VSS because of the availability of linking and cross-project labeling, although still not an ideal solution).
Re:What configuration? (Score:1)
System CM is a lot more than preferences. Think about what happens when you get dynamic library versions wrong.
OpenCM actually could be used for system CM when the bundle model goes in, but it's different enough from the way existing system CM is done that I don't expect it will catch on for that purpose.
Congratulations (Score:3, Interesting)
But why the **** is it (Score:1)
It manages the configuration of the code base etc...
Re:Finally, (Score:2)
I'm still trying figure out how this one will suck a little bit, but less than other systems.
Manual: (Score:2, Funny)
I just love this little pearl from the manual on the site:
This tutorial assumes that your name is "Jack."1
And then as a footnote at the bottom of the page
1. If your name isn't Jack, and you don't know your name, contact your local administrator for support.
The boldness is mine, the italics is theirs
Re:Manual: (Score:2)
On another note EROS spelled backward is SORE. Do you really want to use a sore OS?
I thought linuxconf was supposed to be the start of a 'generic' configuration management system. Supposedly it would work on other UNIXes as well.
Oh well guess just one more. I actually prefer using the very basic tools, like useradd/adduser and eiting the config files sometimes.
linuxconf (Score:1)
Re:linuxconf (Score:2)
Oh and don't take my comment about eros to heart, where I live we have a club called eros.. and it is for just that getting 'sore'....
Re:linuxconf (Score:1)
We have been having some crash problems with the OpenCM server, so if the connection is refused it's always worth trying back later.
Update: OpenCM port submitted (Score:2, Interesting)