Types of Comparisons and Their Features

N1 Service Provisioning System software allows you to perform three types of comparisons:

• Model to Model (M-M)

• Model to Install (M-I)

• Install to Install (I-I)

Model to Model Comparisons

A Model to Model comparison is the simplest type of comparison. It compares the list of components that the provisioning software has installed on one host with the list of components that the provisioning software has installed on another host. This is purely a comparison of the records that the provisioning software has about what it has installed. If there have been out of band changes made to either component list, they will not be detected. A Model-to-Model comparison takes place entirely on the Master Server based on information it has received about what has been deployed.

Model-to-Install Comparisons

A Model-to-Install comparison compares the `just installed' state of the resources in a component or components to their current state on a given host or host set. You can specify that this comparison compares the model to hosts, host sets, or to component level.

A Model-to-Install comparison uses information about what components and subsequent resources have been deployed to a given host based on snapshot information. A snapshot is a record of the state of an installed component immediately after it has been deployed to a host. The component's XML model includes parameters that control the scope of this snapshot. For example, the XML model can list files, such as log files, that should be ignored during a comparison.

When the provisioning software performs a Model-to-Install comparison, the Master Server looks up the list of snapshots for all the components being compared. It sends this list to the Remote Agent on the host where the components are installed. The snapshot information includes rules for any files and directories that should be ignored during the comparison. The Remote Agent then processes these rules. Both Master Server and Remote Agents must be using the same locale for the Model-to-Install comparison to function properly.

Unlike Model-to-Model comparisons, which compare one ideal installation to another, Model-to-Install comparisons compare the actual state of the installed component or components at deployment time against their current state.

Install-to-Install Comparisons

Install-to-Install comparisons compare the current states of the contents of directories in components that the provisioning software has installed on two different hosts. The list of elements (files, directories, and so on) from the reference host being compared in an Install-to-Install comparison are grouped into batches on the Master Server and then sent to the Remote Agent of the comparison host for processing. If you have defined some rules about file types or specific directories or files for the provisioning software to ignore, the Master Server will discard the appropriate items before sending the remainder of the list to the comparison host. The Remote Agents from each host must be set to use the same locale for Install-to-Install comparisons to function properly.

You can provide the provisioning software with scripts to be run before and after the comparison occurs, in case you need to manipulate files before running the comparison or need to clean up any files you have manipulated to prepare for the comparison.

Why Use Scripts in Install-to-Install Comparisons?

If the components you are comparing include resources that stored in a package, a database, or an archive such as a ZIP file, you can use scripts to export or transform the resources before the comparison occurs. Use execNative step to direct the provisioning software to perform native commands such as unzipping or exporting file contents.

Using Scripts in Install-to-Install Comparisons

You can run any native command within the prepare and cleanup blocks. A common usage of these blocks before and after a comparison is to extract the files from a compressed archive and output them to a specified output file, then delete that file during the cleanup.

Unlike the execNative contained in a plan or component, this execNative instance must be contained within either a <prepare> or a <cleanup> block, and cannot make use of any variable substitutions.

When you are performing an Install-to-Install comparison using the HTML user interface, you can select a checkbox labeled include temporary files generated by scripts during comparison. When you select this option, the page refreshes and provides two fields into which you can enter the prepare and cleanup blocks.

You can also specify alternate prepare/generate and cleanup blocks for the target host by un-selecting the appropriate boxes.

You can enter scripts such as these into the fields:

This prepare /generate block specifies the output file for the result of the execNative. The execNative lists the contents of the /tmp directory.

<prepare>
  <execNative outputFile="file.txt" dir="temp">
    <exec cmd="ls">
      <arg value="-l"></arg>
      <arg value="/tmp"></arg>
    </exec>
  </execNative></prepare>

This cleanup block then removes the outputFile, file.txt, from the temp directory.

<cleanup>
  <execNative  dir="/temp/">
    <exec cmd="rm">
      <arg value="-rf"></arg>
      <arg value="file.txt"></arg>
    </exec>
  </execNative></cleanup>