VECT: Versions, Environments, Collections, Trees
by Jeff Blaine
Description
Why VECT?
Differences Between VECT and EMT
Download
Glossary
Description
VECT is a rewrite and reworking of Carnegie Mellon University's
Environment Maintenance Tool. VECT provides a framework for managing
software releases. It permits administrators to roll out software to
their users in a controlled manner by allowing for:
- Trees of software
- Different 'environments' associated with trees. For example, one could point the majority of users at the 'stable' environment but point bleeding edge users and administrators at the 'development' environment, on a per-tree basis. Once software has been tested well, it can be released to the 'stable' environment.
- History. Unless specifically deleted from within VECT, software that was released to a tree N years ago and superceded by a newer version is still available for re-release.
Why VECT?
Note: EMT (below) refers to CMU's Environment Maintenance Tool.
- EMT has no real amount of active support from the authors. While some CMU folks have at least responded to EMT mailing list queries, the lack of source code updates stands as the final word on the EMT project status. While a bit harsh sounding, I feel this is a fair assessment.
- EMT is tied entirely to AFS and has no hooks for using a different underlying filesystem.
- Out of our available operating systems in-house, EMT only ran under SunOS 4.1.3. Efforts to get the 25,000 lines of EMT C source code to work with Solaris 2.5.x and AFS 3.4a failed, let alone Solaris 7 with AFS 3.5 or 3.6.
- EMT has missing features that we wanted implemented (get rid of current logging to email with richtext, allow pluggable filesystem types to work with, etc)
- EMT is "closed" in the sense that it's a gigantic amount of C source code. This is likely the cause for its abandonement. Additionally, EMT uses low-level AFS C library calls. It was determined that this was the reason it would not work properly with AFS 3.4a and higher (apparently it was written to the AFS 3.3 library specs). VECT uses user-level standard AFS binaries to perform its work.
Differences Between VECT and EMT
VECT is different from CMU's EMT in the following main ways:
- VECT is extensible through its filesystem 'modules' and is not tied directly to AFS in anyway. All AFS-related workings are found in the AFS filesystem module for VECT. EMT is for AFS only.
- Currently, VECT's AFS filesystem module does not allow for distributed maintainers via the ADM software. ADM is a tool written by CMU to allow non-AFS-admin users to do specific and regulated AFS-admin tasks. ADM was last updated in 1995 by CMU and the documentation has never been completed. For these reasons, VECT does not use ADM in any way. I wish I had the resources to write an ADM replacement for use with VECT, but I do not.
- Because of the item above, VECT (when using the AFS filesystem module) requires an AFS admin token for the majority of its commands (but not all).
- Only one version of a collection exists in a released environment area at a time. If you 'unrelease' a collection from tree XYZ, then you will no longer have ANY version of collection 'active' in the XYZ tree. You must EXPLICITLY then release the collection/version you want. EMT would leave previous versions still in the depot area so that when you 'unreleased' something, you were simply 'removing' that collection.TIMESTAMP from the depot area, depot would run then and pick up the NEW 'greatest timestamp' version that was there.
- VECT is not based on a client-server model. EMT is.
- VECT is written in a simple, interpreted, and very maintainable language (Python) which compiles easily for a vast number of UNIX platforms.
- VECT does not bother to support EMT's notion of 'object areas'.
- The 'removal' process in VECT for collections, versions of collections, etc is quite different from CMU's EMT. There are 3 commands available in VECT, all of which act immediately on data: vect_unrelease, vect_delete, vect_nuke. That is, there is no 'expiration' of collections over time like CMU's EMT used.
Download
List of all available files at SourceForge
The VECT Project Page
at SourceForge.
Glossary
- AFS - The Andrew File System. From the AFS FAQ: "AFS is a distributed filesystem that enables co-operating hosts (clients and servers) to efficiently share filesystem resources across both local area and wide area networks."
- collection - A collection is a package of releasable software items. Several VECT "versions" of a collection may exist. An example might be GNU Bison (collection name bison).
- Depot - A software product from Carnegie Mellon University. Depot can be found here. A description taken from the Depot homepage: "Depot is a software management tool providing a simple yet flexible mechanism for maintaining third party and locally developed software in large heterogeneous computing environments. Depot integrates separately maintained software packages, known as collections, into a common directory hierarchy consisting of a union of all the collections. This common directory is defined as the software environment. A set of configuration options manages interactions and intersections between collections in the environment."
- destarea - The destarea (specified in the VECT config file as a section titled DESTAREA (see the "Config File Guide") is where software is installed before being released through VECT. When releasing a "collection", VECT uses the collection's destarea as the source for data to release.
- environment - An area for "collections" to be released to. An environment contains released versions of collections of software.
- volspot - A rewrite and extension of the CMU "site" program. A program used with the AFS file system module to pick appropriate server:partition pairs for volume creation or replication.
- system - A platform-dependent tag or name. These are used to delineate "collections" for different platforms. Some examples might be: sun4_51, sgi_6, linux_22 (note for AFS users: these do not have the be the same as the @sys for a system)
- tree - A set of "collections". A tree is actually manifested as a group of related filesystem trees (the "destarea", "environment(s)", and the source area). A tree is the largest unit in the VECT world.
- version - As it applies to VECT, this is the internal version number (a 3 digit integer) associated with a "collection". It does not need to match (arguably should not match) the actual real-world version number of the software it represents. That is, GNU CC 2.8.1 does not need to have VECT version 281.