Configuration Generation Overview

You can model an application as a component so that it can be customized to run in different environments.

For example, suppose that you use a database application to manage your online catalog business. Before you deploy the application to the production environment, you test it in a test environment. These two environments run the same application but are configured differently. When the application is deployed to the test environment, it uses a test database. When the application is deployed to the production environment, it uses the production database.

You can store configuration information about the application, such as which database to use, in configuration files. To support each environment, these files must be customized. These configuration files can include substitution variables that are replaced by variable setting values when you deploy the component.

Not only can you use substitution variables in configuration files, but also in plans and components. For example, you might use them to specify the directory in which to install the application. The provisioning system enables you to define and manage distinct variable settings for each deployment environment.

A substitution variable reference in a configuration file, plan, or component can obtain the following kinds of values:

• User-defined value

• Component-specific value, such as a name or label

• Target host-specific value, such as an IP address

• User-defined value that is specific to a host in the provisioning system

• Value of a session variable

• Value associated with a component that has already been installed

The provisioning system uses a configuration generation engine to replace substitution variable references with the appropriate variable setting values. This engine interacts with the host repository and component repository to resolve values any time that you run a plan to deploy a component.

The provisioning system has a repository for storing variable settings so you can reuse them at a later time. You can view the variable settings that have been used to install components and to run plans to determine the state of the variables. This repository is also used to determine the state of substitution variables when running a comparison with an installed component.

Adding Substitution Variables to Components

When you run a plan that deploys an application to more than one host, you can use configuration generation to automatically replace substitution variables with appropriate values for each host.

To do this, you add substitution variable definitions to your components. These can be used, for example, as a way to configure the directory into which an application is installed. Using the provisioning system, you can define and manage different variable settings for application deployments on each of your target hosts, as follows:

• Each version of a component can declare its own variable definitions.

• Each version of a component has its own variable settings (possibly imported from a previous version).

• Each component can be installed using any of its variable settings.

Substitution Variable Values

The values that the provisioning system substitutes when you install an application can be any of the following:

• Value that you specify

• Component-specific value, such as a name or a label

• Value that is associated with a previously installed component

• Value of a session variable

• Value that is specific to a target host, such as an IP address or a user-defined host variable

Generation Context

Variable substitution happens when a target step is run on a target host. The step can be in a plan or in a component being installed or already installed on the target host. If there is a state associated with the target host and component, it is used to determine the value of a particular substitution variable. The state can include the following:

• Target component – The component on which to perform operations

• Target host – The current host on which the target step is executing

• Target variable settings source – A collection of name-value pairs that override the the default values defined in the component when it is being installed

• Local variables – Any variables in the target step itself, such as those that you have declared in the enclosing block or plan

Input Source

The variable substitution engine operates on any text-based input source in the form of a String or Reader. In practice, however, only these entities are used as input sources:

• Configuration-type resource files

• Input to CLI commands that perform variable substitution on demand

• Some of the component and plan attributes, such as the defaultInstallPath attribute of the <installSteps> element and the command attribute of the <execNative> step

  See Chapter 2, Shared Schema Used by Components and Simple Plans, in N1 Grid Service Provisioning System 5.0 XML Schema Reference Guide, Chapter 3, Component Schema, in N1 Grid Service Provisioning System 5.0 XML Schema Reference Guide, and Chapter 4, Plan Schema, in N1 Grid Service Provisioning System 5.0 XML Schema Reference Guide.