N1 Grid Service Provisioning System 5.0 Plan and Component Developer's Guide

Plan Concepts

A plan, also called an execution plan, is a sequence of instructions that is used to manage one or more components on the specified hosts. For example, an execution plan might install three components and initiate the “startup” control of another component.

A plan can also include a sequence of other plans, which enables common instruction sequences to be written as plans and then shared among plans. For example, a plan might instruct the provisioning system to install three components and initiate the startup control for another.

The provisioning system provides an in-memory representation of the objects expressed by the XML schema. This representation also defines a process for the validation, persistence, and version control for those objects.

When the provisioning system executes a plan, substitution variables that are declared by a component are replaced by actual values. The provisioning system also supports a notification feature that can send email in response to events that are related to plan execution.

Plan Types

The provisioning system supports two types of plans:

The XML schema enforces the distinction between the two types of plans. Thus, you can use a top-level plan that contains calls to other subplans, or a simple plan that contains simple steps but no calls to subplans.

This distinction is important because the steps in a simple plan can only execute on the same set of target hosts, whereas the steps of a composite plan can execute on different sets of target hosts. A composite plan can use one set of target hosts for each simple plan that it contains.

Step Overview

Steps are simple instructions that can be part of both plans and components. The provisioning system supports the following kinds of steps:

Component References

A number of steps can reference components in the following situations:


Example 1–1 Using Component References

Assume that the “Apache” component is installed on a host with the following attribute settings.

Component Instance 

installPath

version

installDate

/opt

1.3 

6/1/01 6:00 p.m. 

/usr/local

1.4 

6/1/01 5:00 p.m. 

/opt

1.2 

6/2/01 5:00 p.m. 

/usr/local/bin

1.4 

6/3/01 5:00 p.m. 

/export

1.1 

6/4/01 5:00 p.m. 

The following shows which installed component is referenced when values for various combinations of the installPath and version attributes are supplied.

installPath

version

versionOp

Result 

Explanation 

None 

None 

None 

The most recently installed component on the target host is used, regardless of the values of version and installPath.

/opt

None 

None 

The most recently installed component in the named install path is used regardless of the value of version.

/usr/bin

None 

None 

ERROR 

No component is installed in the specified path. 

None 

1.4 

=

The most recently installed component that has the specified version is chosen, regardless of the value of installPath.

None 

1.5 

Any 

ERROR 

No component is installed with the specified version. 

/usr/local

1.4 

=, >=

The component that matches the specified installPath and version attribute values is chosen.

/usr/local

1.2 

=

ERROR 

No such version is installed at the specified install path. 

/usr/local

1.2 

>, >=

The values for installPath, version, and versionOp match.

/opt

Any 

ERROR 

If two or more components are installed in the same path and they have the same name, the most recently installed component effectively overwrites any other components that have been installed earlier. Components that have been installed at an earlier time cannot be accessed, even if directly specified.