Provisioning Terminology

Many people have different views of provisioning, the players involved, the data and artifacts they manipulate and the operations used to manage a system. Since there are several provisioning related communities at Eclipse, this page attempts to put forward a set of terminology to facilitate communication between these various communities. While in places there may be multiple and even contradictory definitions, the hope is that there is a preferred usage for most words.

A

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.

Artifact

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

B

Beer

A social transport protocol; also used to mitigate design conflict and as a bug/enhancement voting mechanism.

Bill of Materials

A concrete list of artifacts to be installed. The unit of management in the system. That is, the provisioning infrastructure can manage individual (or collections of) bills of materials. They are analogous to Eclipse configuration in some situations.

C

Curling

A fine team-building game played with ice, brooms, heavy lumps of rock and beer. The only forum in which the Maya and Equinox teams compete ;-)

D

Definition

To make clear one or more meanings of a word. This entry is itself a definition and has been provided as an example of reasonable wiki formatting.

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.

E

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.

M

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.

O

Order

Abstract list of things to be installed (aka wish list)

P

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.

Profile

This term is currently poorly understood due to conflicting interpretations. For now this word is deprecated and replaced with "Order" and "Bill of Materials".

Q

Qualification

Qualification is the operation of discovering what is available on a system, where what is there has not been provisioned by our provisioning mechanism. For example, do we have the dll foo?

R

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.

T

Transport

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.

Touchpoint

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.

U

Update Manager

The old generation of Eclipse provisioning technology that we are seeking to replace. Used in Eclipse until release 3.3.