Equinox Incubator - Provisioning Overview

Requirements

While there are many possible requirements one could place on a provisioning system, the work here is focused on creating a robust, extensible provisioning base for Eclipse-based systems on client machines. We will purposely keep the scope of this work quite narrow but allow for potential extensions and improvements as we are incrementally successful. Of course, the set of high-level requirements to be addressed by this workarea will evolve over time. The following is an initial set:

Multiple Configurations

Many users or systems contain multiple configurations of Eclipse bundles. The provisioning infrastructure must be able to manage these configurations

Stand-alone operation

The provisioning system must be able to run as a standalone application and manage/configure Eclipse systems that are not running at the time.

Sharing

Given multiple configurations of bundles on a single machine, the provisioning system should take every opportunity to shared the physical and inmemory storage associated with bundles.

JRE and root files

We must be able to update the JRE, root files and all other aspects of an Eclipse configuration

Self-aware

The provisioning system itself is an Eclipse-based system and must be able to operate on itself.

Simple workflows

End-users should follow a set of simple workflows when doing simple operations

Standards

The provisioning work should use existing standards as much as possible and where new designs, approaches, formats or APIs are developed, they should be suitable candidates for standardization.

Design

Of course, the design too will evolve over time. To kick off the effort we have sketched out and prototyped some ideas. The basis for this design is the desire to factor a provisioning system into constituent parts and allow those parts to be replaced and reassembled as needed. In particular we have identified the following high level concepts.

Agent

The provisioning infrastructure on client machines is generally referred to as the agent. Agents can manage themselves as well as other profiles. An agent may run separate from any other Eclipse system being managed or may be embedded inside of another Eclipse system. Agents can manage many profiles (see below) and indeed, a given system may have many agents running on it.

Profile

Profiles are the unit of management in the system. That is, the provisioning infrastructure can manage individual (or collections of) profiles. Profiles are analogous to Eclipse configuration in some situations. For now we have chosen to introduce this new term to separate the conceptual profile from the implementation configuration.

Artifact

Artifacts are the elements that are ultimately provisioned to a profile. For example, Eclipse bundles are artifacts.

Metadata

As with the original Update Manager, there is a need for metadata that describes artifacts separate from the actual artifacts themselves. This allows the provisioning system to reason about profiles hypothetically without having to actually incur the cost of downloading all the content. Broadly speaking the provisioning metadata envisioned here takes the form of extensible Installable Units (IUs). As the name implies, IUs describe things that can be installed, updated or uninstalled. They do not contain the actual artifacts but rather essential information about such artifacts (e.g., names, ids, version numbers, dependencies, etc). The metadata should allow dependencies to be structured as directed acyclic graphs without forcing containment relationships between nodes.

Repository

Both metadata and artifacts are organized into repositories. Repository structure, layout and access has long been the source of much debate and discussion. We do not intend to fight that battle here. Rather, the provisioning system must be extensible and thus allow for a wide range of repository formats to be represented. The pervasive notion of downloading or managing repository content is mirroring. Rather than downloading artifacts etc, they are mirrored locally.

Transports

As the name implies transports are the mechanisms by which artifacts, metadata etc are mirrored around the system. The set of available transports must be extensible and the programmatic interface to transports should allow for progress monitoring, cancellation and restart as appropriate. The incubator work will focus on a small set of transports (e.g., HTTP) sufficient to do standard Eclipse install management.

Director

Directors are responsible for determining what should be done to a given profile to reshape it as requested. That is, given the current state of a profile, a description of the desired end state of that profile and metadata describing the available IUs, a director produces a list of provisioning operations (e.g., install, update or uninstall) to perform on the related IUs. Directors are also able to validate profiles and assist in the diagnosis of configuration errors. Note that directors may range in complexity from very simple (e.g., reading a list of bundles from a static file) to very complex. In this incubator we will create a director sufficient to achieve Update Manager-like function.

Engine

The engine is responsible for determining how to achieve the desired provisioning operations as determined by a director. Whereas the subject of the director's work is metadata, the subject of the engine's work is the artifacts and configuration information contained in the IUs selected by the director. Engines cooperate with repositories and transport mechanisms to ensure that the required artifacts are available in the desired locations.

Phase

During execution the engine traverses through a set of phases (e.g., fetch, install, configurre). At each phase all the IUs being operated on have an opportunity to participate in the lifecycle. The mechanism by which they specify their participation is undecided at this point.

Touchpoints

IUs can be stamped with a type. Using this type the engine identifies the touchpoint responsible for marrying the IU with the related system. For example, an IU of type "Eclipse bundle" would be handled by the Eclipse Touchpoint. That touchpoint is responsible for putting the bundle in the appropriate spot, adding it to the Eclipse configuration files and setting any related/described settings. The set of touchpoints is open-ended.

The interactions between some of these concepts are depicted in the view diagram shown below.