Chapter 2 Variable Substitution in Repository Component Targeters

This chapter describes new functionality for variable substitution in Repository Component Targeters.

Changes to Elements for Variable Substitution in Repository Component Targeters

This table updates the tables in Using Substitution Variables in Sun N1 Service Provisioning System 5.2 Plan and Component Developer’s Guide:

If the name attribute of any of the above repository component targeters, or the name, path and/or version of the <component> contain variable substitution:

• The browser user interface does not display the component in the list of subplan parameters.

• You cannot specify the component version or variable settings for a component in the command line interface, through the -comp or -vs options, if the name, path, and/or version attributes of the <component> or the name attribute of the <toplevelRef>, or <nestedRef> is substituted by a variable.

Examples Illustrating Variable Substitution in Repository Component Targeters

This section provides simple examples to explain how the introduction of the new variable substitution for repository component targeters feature allows dynamic targeting in the N1 Service Provisioning System.

Look at the example plan below. The component name in the block named secondInstall is substituted by a variable, varA, where the default value is comp2.

<varList>
  <var name="varA" default="comp2"/>
</varList>
<simpleSteps>
  <install blockname="firstInstall">
    <component name="comp1" path="../apps" version="1.2"/>
  </install>
  <install blockname="secondInstall">
    <component name=":[varA]" path="../apps" version="1.3"/>
  </install>
</simpleSteps>

In this case, the browser user interface of the N1 Service Provisioning System does not show comp2, since comp2 is substituted by a variable.

You can only specify the settings for the first component in this example, since it is not substituted by a variable. This plan could be run with the following command:

# pe.p.run -PID NM:/plan1 -tar H:NM:host1 
-comp "1.1" -vs "varsetname" -pto 100 -nto 100

As explained in Sun N1 Service Provisioning System 5.2 Command-Line Interface Reference Manual, the -comp argument for the pe.p.run command is used to specify component versions to install as a part of the plan and subplans. Versions are ordered according to component selectors within subplan prompts. Each referenced component must be represented in this list. Use the component version number, or “+” for default, “#” for recommended, and “-” for latest. Do not specify when there are no component versions.

With the inclusion of the new Dynamic Targeting feature in this version of the N1 Service Provisioning System, do not specify a component whose name, path, or version number contains substitution variables.

The -vs argument for the pe.p.run command is used to specify variable settings to use with each selected component version. Use variable settings name, or “+” for default. Do not specify when there are no variable settings.

With the -vs argument, as with the -comp argument, do not specify a component whose name, path, or version number contains substitution variables.

As with the browser user interface, any components that have been substituted by variables are not provided in the output of the pe.p.lp command.

You can therefore also use the output of the pe.p.lp command to list those components for which you can specify settings when using the pe.p.run command.

See the Sun N1 Service Provisioning System 5.2 Command-Line Interface Reference Manual for explanations of the other terms used in this command.

This table updates the pe.p.run table in Overview of the pe Commands in Sun N1 Service Provisioning System 5.2 Command-Line Interface Reference Manual:

Do not specify settings for components that are dynamically targeted.

Another example that addresses a slightly different situation is shown below:

<varList>
  <var name="varA" default="comp2"/>
</varList>
<simpleSteps>
  <install blockname="firstInstall">
    <component name="comp1" path="../apps" version="1.2"/>
  </install>
  <install blockname="secondInstall">
    <component name=":[varA]" path="../apps" version="1.3"/>
  </install>
  <install blockname="thirdInstall">
    <component name="comp3" path="../apps" version="1.3"/>
  </install>
</simpleSteps>

Suppose this plan were run with the following command:

# pe.p.run -PID NM:myplan -tar <target host list>
 -comp "2.0,3.0" -vs "VS1,VS3" -pto 100 -nto 100

Suppose that VS1 and VS2 both are valid names of existing component variable settings.

In this example, although there are three components being installed, only two values for the -comp parameters and for the -vs parameters have been specified with the pe.p.run command. The result of this command would be as follows:

• Version 2.0 of component comp1 would be installed with variable setting VS1.

• Version 1.3 of component comp2 would be installed with the default variable setting for comp2.

• Finally, version 3.0 of component comp3 would be installed with variable setting VS3.

The targeter component name that is substituted by a variable is skipped because specifying settings for dynamically targeted components is not supported at the command line or in the browser user interface.