Difference between revisions of "Provisioning Terminology"

Revision as of 16:46, 10 April 2007

One goal of the Ganymede Provisioning Workshop is a consistent and useful lexicon of provisioning terminology. We provide this page as a working space for this effort. Thought the workshop we will allow multiple and even contradictory definitions with the hope that prefered usage for most words can be identified before the event is over.

(We have created many sections to simplify ordering and reduce editing conflicts. See example definition.)

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.

B

Bill of Materials

A concrete list of artifacts to be installed. Analagous to an OSGi configuration.

C

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.

F

G

H

I

J

K

L

M

N

O

Order

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

P

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.

Q

R

S

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

V

W

X

Y

Z