Document Number SC30-4092-03
| Note |
|---|
|
Before using this information and the product it supports, read the general information in Appendix B, Notices. |
Third Edition (September 2005)
This edition applies to Release 3 of the Autonomic Computing Toolkit and to all subsequent releases and modifications until otherwise indicated in new drafts.
(C) Copyright International Business Machines Corporation 2005. All rights reserved.
U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Working with Solution Installation and Deployment
Installing the Solution Installation and Deployment samples scenario
Running the Solution Installation and Deployment samples scenario
Running the Solution Installation and Deployment FNPIM scenario
Running the Solution Installation and Deployment InstallAnywhere scenario
Appendix A. Getting help, service, and information
This guide provides information on solution installation and deployment for the Autonomic Computing Toolkit.
This edition of the Solution Installation and Deployment Scenario Guide includes the following changes:
This guide is for Autonomic Computing Toolkit users who want to run the Solution Installation and Deployment scenarios and understand how they function.
The latest softcopy versions of documentation are available on the autonomic computing IBM developerWorks(R) Web site at:
www.ibm.com/developerworks/autonomic
The autonomic computing library consists of the following documents:
The HTML version of this guide and other related publications is accessibility-enabled for use with the IBM Home Page Reader.
For the latest news and tips on general autonomic computing topics, go to the autonomic computing Web site at:
You can also download the Autonomic Computing Toolkit, documentation, and access additional information from the developerWorks Web site at:
www.ibm.com/developerworks/autonomic
Here you will find information about general autonomic computing concepts, an overview of the Autonomic Computing Toolkit, and most importantly, articles, and tutorials that show you how to apply the tools from the Autonomic Computing Toolkit in real-life situations. After you decide which pieces of the Autonomic Computing Toolkit you need, you can easily download the code right from this Web site.
Your feedback is important to help us provide the highest quality information. If you have any comments about this guide, you can submit them on the IBM autonomic computing Web site at:
www.ibm.com/developerworks/autonomic
then select Support for Toolkit forum.
This chapter gives you an introduction to autonomic computing using the Solution Installation and Deployment scenarios.
To satisfy the needs of users, computing systems have become more complex and more costly to install and maintain. Today, system administrators must deal with hundreds of subsystems. With thousands of parameters just to keep this running, administrative costs often far outstrip hardware and software acquisition costs.
Autonomic computing is about satisfying these needs with dramatically less human administration. Autonomic systems adapt to changing conditions and workloads, heal over errors and failures within themselves, and proactively defend against attack. These systems manage themselves and remove complexity from the lives of administrators and users.
The Autonomic Computing Toolkit is a collection of technologies, tools, scenarios, and documentation that is designed for users wanting to learn, adapt, and develop autonomic behavior in their products and systems. Scenarios are provided to show how the technologies can be used in realistic situations.
Solution Installation and Deployment, an IBM Self-Managing Autonomic Technology, enables software solutions to be deployed and supported with reduced human interaction by creating the following common services:
Using this technology can help you consistently plan for and deploy IBM and non-IBM solutions in less time with fewer resources.
The Solution Installation and Deployment architecture is demonstrated using a set of scenarios targeting the self-configuring aspect of autonomic computing. These include the following scenarios that focus on different aspects and implementations of the architecture:
There are five levels of autonomic maturity: basic, managed, predictive, adaptive, and autonomic (see the Autonomic Computing Toolkit User's Guide for more information on autonomic maturity levels). The Solution installation and deployment scenarios aim to be predictive in nature (level 3), enabling the software installation process to require less user intervention. The installation process can predict and alert you when a key dependency is missing, as well as coordinate and track change management actions. This predictive behavior enhances the reliability and maintainability of the system.
The Samples scenario is a teaching tool, introducing the core components that make up the Solution installation and deployment architecture, and then relating them together to illustrate the benefits of the architecture. It also identifies how installation behavior is defined and carried out, and allows the user to verify each step of the installation by viewing the repository of installed components.
In contrast, the FNPIM and InstallAnywhere scenarios show you how Solution Installation and Deployment provides true end-to-end packaging and installation services. Both scenarios perform the same installation, but use different installation engine products from an IBM partner, Macrovision.
Using these scenarios, you will become familiar with the concepts and formats of Solution Installation, an IBM Self-Managing Autonomic Technology. You will see examples of how you can package your own software solutions using these technologies and begin realizing the benefits of a predictive installation process. By describing the solution in advance, you reduce the burden on your customers.
This chapter gives an introduction to the Solution Installation and Deployment technologies in relation to scenario operation.
To get the maximum value out of running the scenarios, you should first attain a basic knowledge of the Solution Installation and Deployment technologies. The purpose of the scenarios is to demonstrate the capabilities of Solution Installation and Deployment technology and demonstrate the technology using actual interactive examples. You will see how the installation dependencies are constructed and carried out, and see how these changes affect the results of the installation. There are many other references available that will teach you more about Solution Installation and Deployment. For a start, you can see the main IBM Autonomic Computing Web site at:
Solution Installation and Deployment is a collection of common software packaging and deployment technologies that provides a universal means by which software can be bundled and deployed across most operating environments. In an installation scenario on the predictive autonomic level, it evaluates checks and dependencies of the software that is to be installed as well as dependencies of currently installed software that might be affected by the new installation. An adaptive autonomic solution collects information about a problem, then makes the necessary adjustments to provide a solution.
The Solution Installation technology creates a baseline for delivering and supporting a component model. Figure 1 illustrates the runtime components: the exploiter components, the Solution Installation components, and the hosting environment components.
Figure 1. Exploiter components diagram
The scenarios described in this guide refer directly to the following Solution Installation and Deployment terminology:
An installable unit (IU) is a software entity that can be deployed to an IT system. This entity could be simple, such as a single module or configuration change, or complex, such as multiple applications across multiple systems. Depending on the architecture of the IU, it contains one deployment descriptor and one or more artifacts to be deployed. The deployment descriptor is an XML file that describes the content of an IU, its checks, and its dependencies. An artifact is a deployable file that defines the required actions to install an IU to a managed resource. Solution Installation and Deployment enables you to define IUs with dependency validation to ensure the integrity of the existing IT environment. The solution installation and deployment technology spans traditional product boundaries by creating a baseline for delivering and supporting a component model. This component-based approach ensures an easy to use, out-of-box experience for customers.
The software deployment program communicates with the Solution Installation components using Solution Installation application programming interfaces (APIs). Macrovision FLEXnet Publisher is an example of a software deployment program.
The dependency checker is an independent component. The dependency checker takes input from the following sources:
Before installing any artifact, the dependency checker uses this information to determine whether the dependencies are met by the hosting environment. The dependency checker provides methods for determining whether dependencies can be satisfied for change management operations on a specific IU. The dependency checker provides the following functions:
The following list contains the primary dependencies that can be defined:
The installation database refers to the databases and registries that are used during the installation and maintenance of IUs. The installation database holds the following types of data:
The change manager is a central component of the solution installation and deployment technology. Taking the deployment descriptor as input, the change manager coordinates change management operations across the appropriate hosting environments, utilizing other runtime components such as the dependency checker and communicating with the registry and touchpoints. The primary interface for installation programs is the change manager.
The change manager does not perform the actual actions of a change management operation. Based on the requested change management operation (create, update, undo, or delete), the descriptor files define the actual actions to be carried out. The change manager passes this information on to the touchpoint associated with the target hosting environment and the touchpoint carries out the actions. However, the change manager does coordinate these operations and tracks their progress and success. If an operation fails, it is the responsibility of the change manager to initiate activities such as backing out the necessary changes to put the system into a known and stable state. In general, the change manager provides the logic to:
The installation of optional components of an installable unit is supported by features. Feature processing can be quite complex because it introduces new levels of interdependencies. Installation groups are mechanisms for grouping commonly associated features. For instance, by choosing to install a specific installation group, a predefined set of features is selected. After the user selects features, the installation program determines which installment units to deploy.
A touchpoint implements the manageability interface on behalf of a hosting environment. Solution Installation runtime components use the touchpoint to query properties and information about objects hosted by the hosting environment.
The touchpoint also carries out specific actions passed into it by the Solution Installation runtime. There is one touchpoint for each hosting environment in a system.
A hosting environment is a container for a set of hosted resources. Each instance of a hosting environment contains properties that can be queried through the touchpoint interface, or through the objects it is hosting.
Examples of hosting environments include the operating system, IBM WebSphere(R) Application Server, a database, or other layered applications. For the operating system hosting environment, such properties as available disk space, number of microprocessors and their speed, total memory, and OS version are specified.
The Solution Installation and Deployment architecture defines a Root IU as the smallest unit of packaging. Root IUs have features, but solution module definitions (SMDs), container installable units (CIUs), and smallest installable units (SIUs) do not. A single solution is likely to be made up of multiple packages (Root IUs) each containing multiple SMDs, CIUs and SIUs. A root IU defines the deployable units of software in the solution. These units of software are a set of conditioned IUs. The conditioned IUs that can be defined in a root IU are smallest IUs (SIUs), container IUs (CIUs), or solution modules. These IUs can be defined as either base content or selectable content.
Every deployment descriptor is a root IU. This root IU can contain or reference other IUs within its definition. The deployment descriptor for the root IU is defined by the rootIU element. Each deployment descriptor contains one and only one rootIU element. The rootIU element contains information about the deployment descriptor and the schema against which the descriptor is created. The deployment descriptor has one or more IU elements with one or more feature and installation groups, a topology element, and a files element that in turn has one or more file elements.
Features provide the mechanism that enables a user to select installable units (IUs) to deploy from within the root IU. For example, when you are installing a new product you can choose a typical or custom installation. If you choose a custom installation, the first question you must ask yourself is what features do you want to install: each feature corresponds to an IU, which includes an artifact and descriptor. The artifact can be thought of as the payload that Solution Installation and Deployment technologies deliver. A feature can contain one more nested subfeatures and IUs. Features are associated with IUs. For each defined feature, the defined IU can be partitioned into required content and selectable content. Required content indicates the IUs that have been deployed independent of what the user selects. Selectable content indicates that the user can select content and IUs are deployed based on what the user selects. During the installation process, features are registered. Because features are registered, you can define dependency checks against the features. Each feature has a unique name within a root IU. The change manager uses the unique name to process the feature. In the same way that you can perform a custom installation of a program by selecting options, features support the installation of optional components of an IU. Feature processing can be quite complex because it introduces new levels of interdependencies. Installation groups are mechanisms for grouping commonly associated features. For instance, by choosing to install a specific installation group, a predefined set of features would be selected. Keep in mind that Solution Installation and Deployment technology keeps track of not only these features but any dependencies associated with them.
The Universal Unique Identifier (UUI) element is a required element that is the unique identifier for the root IU during its life cycle. When an IU is modified during its life cycle, for example, when it is updated, the UUI remains the same. This feature allows Solution Installation and Deployment to keep track of different versions of the product
An installation that uses Solution Installation begins with the software deployment program. The software deployment program locates the IU within the media used to deliver the product (typically a CD or DVD). A pointer to the IU is passed to the dependency checker for loading. The dependency checker locates the deployment descriptor within the IU and parses its contents.
The software deployment program queries the IU for the software name, along with any installation groups and features that can be selected. The software deployment program presents this information to the user and records the choices made by the user. Based on the list of features selected, the software deployment program queries the IU for variables that can be set by the user (for example, an installation directory).
With the complete list of selections available, the software deployment program asks the dependency checker to evaluate the installation of this package. The dependency checker compares the requirements of the selected features against the hosting environment into which it is installing. To do this, the dependency checker queries the touchpoint of the hosting environment, and queries the installation database (depending on the type of check), for the current information, and checks that information against the information which is dictated by the deployment descriptor. Typical requirements check for space, operating system or prerequisite software. A list of results is returned to the software deployment program.
Assuming that overall requirements are positive, the software deployment program calls the change manager to perform the actual installation. The change manager passes the installation artifacts to the touchpoint for implementation. The touchpoint performs each action described in the install artifacts. Typical actions include creating directories and copying files to the target system, updating a file, or adding keys to a registry.
When the actions are complete, entries are created in the installation database for each IU installed and relationships are created among the IUs where applicable. The change manager returns to the software deployment program indicating a successful change.
The schemas used for the solution installation and deployment technologies are documented in the following specifications:
Both specifications are included in the Autonomic Computing Toolkit and are available in the Autonomic Computing Information bundle.
These documents provide the background information needed to understand the Solution Installation and Deployment scenarios.
The purpose of this specification is to define the schema of an XML document describing the characteristics of an IU of software that are relevant for its deployment, configuration, and maintenance. The XML schema is referred to as the IUDD schema.
IUDDs are intended to describe the aggregation of IUs at all levels of the software stack, including middleware products aggregated together into a platform, and user solutions composed of application-level artifacts which run on such a platform. The XML schema is flexible enough to support the definition of atomic units of software (smallest installable units) as well as complex solutions.
A solution is any combination of products, components or application artifacts addressing a particular user requirement. This includes what would traditionally be referred to as a product offering (for example, a database product), as well as a solution offering (e.g. a business integration platform comprising multiple integrated products), or a user application (for example, a set of application artifacts like Java Platform 2 Enterprise Edition (J2EE) applications and database definitions). All the software constituents of a solution can be represented by a single IUDD as a hierarchy of installable unit aggregates. The top-level aggregation is the root installable unit. In addition to the installable units that comprise a solution, the IUDD also describes the logical topology of targets onto which the solution can be deployed.
This specification defines:
An IU is a logical component that can be selected for installation. An IU package (or packaged installable unit) contains files to be installed, files that implement change management operations, and a set of manifest files which include a deployment descriptor that describes the install characteristics of the IUDD, and a media descriptor that describes the binding (or physical locations) of the files. This document describes the IU package format.
The main objective of this document is to define a common IU package format consistent with the solution installation architecture. Packages in this format need to be installed in local or distributed environments. Different package types are defined for a single zip file, fixed-sized removable media, and network location. Other formats may be accommodated in the future. IU packages can be used with packages in existing packaging standards.
This document specifies the common IU package format and related design. In particular, the following areas will be covered in this document:
The Autonomic Computing Toolkit scenarios demonstrate how you can use the autonomic solution installation and deployment technologies to improve the packaging and installation processes for software solutions.
The Samples scenario bundle must first be installed before the samples can be executed. The installation of the bundle establishes whether the Integrated Solutions Console is to be used to manage and control the samples. Once the Samples scenario is installed, each sample can then be executed and analyzed.
The Macrovision scenarios operate slightly different than the Samples Scenario in that the installation of the bundle is the actual scenario. These bundles are examples of real packaging and installation implementations. Both scenarios install three IUs, each one containing a single file. The installation bundle is in the form of a Solution Installation and Deployment Solution module bundle. The bundle contains the solution module descriptor XML file (PackagedIU.xml) and the files that are to be installed. The installation executable file contains the solution installation and deployment runtime. First, the installation logic checks for the existence of the solution installation and deployment runtime. If it is not present on the system, the solution installation and deployment runtime is automatically loaded.
Then the installation logic prompts for the location of the bundle file and passes it to the solution installation and deployment runtime. The solution installation and deployment runtime reads the XML descriptor and checks the dependencies that are specified in the descriptor. The installation logic, for the purposes of this demo, echoes the dependency results to an Integrated Solutions Console panel so the results can be observed. If a dependency fails, the user is notified and corrective action can be taken. After checking dependencies, the installation logic reads the XML descriptor to find out what directories must be created and what files are to be installed. The files are then extracted from the bundle and copied to the file system. The installation logic then displays a completion page, indicating that the installation process has finished.
This chapter contains information on installing the Solution Installation and Deployment Samples scenario.
The solution installation and deployment technologies address many aspects of complex packaging and installation solutions. For this reason, a set of samples have been created with the purpose of isolating specific features of the technology and demonstrating them in a meaningful and interactive way.
All the samples are managed and controlled using an Integrated Solutions Console component plug-in. The same plug-in is used to control the Problem Determination scenario, which is also available in the Autonomic Computing Toolkit. This provides similar control over the various scenarios presented in the Toolkit. The samples do not require the Integrated Solutions Console; however, it is the preferred method for demonstrating in the Autonomic Computing Toolkit. Later sections will describe how to run the samples outside of the console using command line operations.
This Solution Installation and Deployment scenario contains the following samples:
These samples show how the Solution Installation and Deployment technology can be used in realistic situations to achieve self-configuration as defined by the autonomic computing architecture
Before installing the Samples scenario, you will need to make certain that you have completed all prerequisites and dependencies.
The samples for Solution Installation and Deployment are included in the Solution Installation and Deployment Samples scenario bundle; it provides the customized components to establish the specific Samples as well as demonstration support code to actually control the Samples operation.
The Solution Installation and Deployment Samples scenario can be implemented using the Integrated Solutions Console bundle. This bundle is available in the Autonomic Computing Toolkit. Install the Integrated Solutions Console bundle first followed by the Solution Installation and Deployment Samples bundle. You will need the Integrated Solutions Console user ID and password to run the Samples from the console.
If the Integrated Solutions Console bundle has already been installed on the system for either development purposes, or to run the Problem Determination scenario, then there is no need to obtain and install the bundle again. Simply install the Solution Installation and Deployment Samples scenario to run the Samples.
To run the Samples by command line does not require the Integrated Solutions Console bundle to be installed. The installation panels for the Samples Scenario allows the user to choose which method is to be used to run the samples.
For supported platforms, see www.ibm.com/developerworks/autonomic/table.html
See the Autonomic Computing Toolkit User's Guide for disk space and platforms supported.
To install the Solution Installation and Deployment Samples scenario, perform the following steps:
java -jar SISamples_v3-0-0_os400.jar -console
To uninstall the Solution Installation and Deployment Samples scenario, perform the following steps:
For Linux and AIX and sun Solaris Operating Environment:
java -jar <SI_SAMPLES_HOME>/_uninst/uninstall.jar -console
This chapter describes how to run the Solution Installation and Deployment Samples scenario. Running the samples with the Integrated Solutions Console is described first, followed by using the alternative command line method.
If you are using the Integrated Solution Console, you must activate it before control of the scenario can begin.
In order for the samples to function in the Integrated Solutions Console, the ISC_Portal server must be started.
In order to start the server, run the following commands from the Integrated Solutions Console/AppServer/bin directory on a command line:
startServer ISC_Portal
or use the provided shortcuts, shown below, to both start and stop the required server:
To activate any of the samples, perform the following steps:
The same operational look and feel is shared among all the samples when using the Integrated Solutions Console. This is accomplished by having the Integrated Solutions Console divided into two major screen areas: Navigation on the left and Work on the right. The navigation area is a standard directory structure tree to allow drilling down to specific Solution Installation and Deployment Samples. The work area provides the user interface interaction with the Samples.
The navigation area allows the user to drill down to the specific scenario of interest. If the solution installation and deployment sample scenario has been installed, the navigation area will contain a root level folder called Autonomic Computing Scenarios. If this folder does not appear on the navigation area, the samples have not been successfully installed. See Installing the samples scenario and Uninstalling the Solution Installation and Deployment samples scenario for installing and uninstalling the samples.
Expanding the Autonomic Computing Scenarios folder reveals the scenarios that have been installed from the Autonomic Computing Toolkit. For this release of the Toolkit, two scenarios are available; the Problem Determination scenario and the Solution Installation and Deployment Samples scenario. Each installed scenario will be represented as an expandable category under the Autonomic Computing Scenarios folder. Expanding the Solution Installation and Deployment Samples category shows two additional nodes; Solution Install Scenario Description and Samples. Their functions are as follows:
Use the work area to control and display the sample. The work area concept is similar for all scenarios and samples; however, the actual content displayed may differ slightly to accommodate the uniqueness of each scenario or sample.
The work area for all samples in the scenario consists of five portlets. The tasks run and the information displayed by these five portlets is similar for all samples.
Each sample has multiple steps that the user controls to proceed through the scenario. The Description panel gives a summary of each of the steps, identifying the Solution Installation and Deployment actions that have occurred. Useful links are also included, where applicable, that provide additional details.
All description panels include the following sections:
Use the control panel to start the selected sample by performing an install of the sample, and to stop the selected sample by uninstalling the sample. The control actions appear in the Control panel as links. Selecting a link invokes the corresponding start or stop action. At any point in time, only those links that are allowed will be enabled, depending on the state of the sample.
The Deployment Descriptor panel contains one or more links to the specific descriptor files that relate to the selected sample. A short description accompanies each descriptor file link identifying it purpose. Selecting a descriptor link displays the contents of the deployment descriptor file in a separate window. The user can view the descriptor file while the sample is executing. Each sample has unique descriptor files.
Each sample has a unique log file that is generated dynamically while the sample executes. This log file contains key information on the progress of the sample and is mirrored to the Log View panel for the user to observe while the sample is running. The Log View panel is automatically updated during each phase of the sample to illustrate results of events and actions as they take place. The information in this panel is updated sequentially, with the latest events and actions occurring at the bottom of the panel.
The UI View panel allows the installed IUs to be examined as each sample is executed to verify the Solution Installation and Deployment operation. This panel is automatically updated at the completion of each command during the execution of the sample. This panel displays the output of the listIU command. ListIU is a command provided as part of the Solution Installation and Deployment technology that retrieves IU information from the Solution Installation and Deployment repository. By dumping the contents of the repository, the user can verify the success of each installation.
The information shown in the IU View panel has been filtered and formatted for the Integrated Solutions Console samples scenario. The complete raw information can be observed by using the command line operation:
<SI_SAMPLES_HOME>/bin/listIU.bat(sh)
and observing the results in the listIU.out file in the same directory.
The directory structure established for all samples is described
below:
SolutionInstallSamples
|
+--- _uninst
+--- bin
| +---ISCComponent
| | deploy_scicomp.bat(sh)
| | ISC_sisamples.war
| | LaunchWebConsole.htm
| | removesicomp.bat(sh)
| |
| +---configure.bat(sh)
| delete.bat(sh)
| fix.bat(sh)
| install.bat(sh)
| listIU.bat(sh)
| listIU.out
| migrate.bat(sh)
| rollback.bat(sh)
| samples.properties
| setenv.bat(sh)
| siconfig.properties
+---docs
| ACTK_SIScenario.pdf
|
+---lib
| sisamples.jar
|
+---logs
+---readme-toolkit
| readme.htm
|
+---samples
+---java_custom_action
| java_custom_action.zip
| MyCustomAction.class
| sample.log
|
|
+---family
Daughter_1.2.0_Fix.zip
Daughter_1.2.0_Fix.zip
Family_1.2.0_Base.zip
Family_1.5.0_Incremental.zip
Family_2.0.0_Base.zip
Response_1.2.0.properties
Response_1.2.0_fix.properties
Response_1.2.0_init.properties
Response_1.5.0.properties
Response_2.0.0.properties
Response_2.0.0_migrate.properties
sample.log
Each sample subdirectory (java_custom_action and family) contains all the artifacts needed to run the sample and to display the information in the work area of the Integrated Solutions Console.
The following artifacts will be placed in each sample's subdirectory:
In addition to the sample subdirectories, the scenario home\bin and \lib will also contain the following files:
Java -Ddebug=true com.ibm.ac.si.cm.cli. ManageIU -o install -r sample1 -p package.zip
Java -Ddebug=true com.ibm.ac.si.cm.cli. ManageIU -o delete -r sample1 -p package.zip
This sample demonstrates the usage of the Java Custom Action feature of the Solution Installation and Deployment technology. This sample demonstrates only one possible custom action that can be performed using this feature. By running and examining this sample, users will understand how to utilize the Java custom action feature in their own installations.
The Java custom action sample shows how to create a new directory with a text file as part of a typical installation. The sample consists of a single zip file containing the files to be installed as an Installable Unit (IU), two XML files that define the installation characteristics and the Java custom action to be executed, and a Java class to perform the custom task.
Contained within the zip package are the following files:
By installing the sample, the defined Java custom action for this sample is executed by the installer. The directory created by the Java custom action is <SI_SCENARIO_HOME>/samples/java_custom_action/jca_test and the file created in that new directory is named jca_test.txt.
The user interacts directly with the sample by:
The Java Custom Action sample is included in the Solution Installation and Deployment Samples Scenario bundle. An installation option lets the user choose the method of operation for the samples. Choosing to run the samples using the console requires that the Integrated Solution Console be installed.
The Integration Solutions Console must be activated before control of the sample can begin. See "Activating the console for the scenario". To begin running the sample, navigate to the Java Custom Action Control panel.
The Java Custom Action sample uses the following control links to operate the sample:
The following steps run when you click Install Sample.
The following steps run when you click Un-install:
Both the Install and Un-install links invoke the following command to install or uninstall each sample:
Java -Ddebug=true com.ibm.ac.si.cm.cli.ManageIU -o install/delete -r samplename -p packageFile
where:
Install/delete indicates whether the sample is to be installed or removed.
SampleName identifies the text string stored in the Solution installation repository and used by the listIU program to retrieve the IU content specific to the sample.
PackageFile indicates the name of the package file that contains the deployment descriptors and the artifacts to be installed.
The Solution Installation and Deployment setenv script will be invoked to set up the class path.
The Java Custom Action sample uses two descriptor files:
The descriptor files can be visually correlated with the Log view panel output.
The Log view panel is used to display the events and actions taken during the installation and un-installation of the Java custom action sample.
Installing the Java custom action sample yields the following log view output:
--> ManageIUInstaller started Primary Operation is: CREATE --> Constructing MediaReader. URI is: java_custom_action.zip --> Running Parse Deployment Descriptor via Dependency Checker --> Getting Target Hosting Environment. --> Running checkSystem... --> Executing ChangeManager Change() method [ManageIUInstaller has received a change Event: SUBMITTED ] [Total Ops: 0, Total Completed: 0, Total Errors: 0] [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 1, Total Completed: 0, Total Errors: 0] --> ChangeManager Change() method returned to calling program (ManageIU) [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 1, Total Completed: 0, Total Errors: 0] Set context = jca_test/jca_test.txt install location = jca_test Executing My Custom Action Code Get Context = jca_test/jca_test.txt [ManageIUInstaller has received a changeCompleted Event: COMPLETED] [Total Ops: 1,Total Completed: 1,Total Errors: 0] --> ChangeManager Touchpoint and CE Thread completed. Status of CM Operations Java Custom Action StartTime: 8/12/05 4:50 PM EndTime: 8/12/05 4:50 PM CMOP: Create Errors: [] State: COMPLETED
Note that the Primary Operation is Create for the installation, and java_custom_action.zip is the install package being operated on. The change management operation (CMOP) indicates that the IU, java_custom_action, now has a status of Create. This is the only IU in the java_custom_action package.
Uninstalling the Java Custom Action sample yields the following output:
--> ManageIUInstaller started Primary Operation is: DELETE RootTypeID target is: RootIUTypeID[CC05DC31804627BBA6E6661C48BF1A81,1.2] --> Running checkSystem... --> Executing ChangeManager Change() method [ManageIUInstaller has received a change Event: SUBMITTED ] [Total Ops: 0, Total Completed: 0, Total Errors: 0] [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 1, Total Completed: 0, Total Errors: 0] --> ChangeManager Change() method returned to calling program (ManageIU) [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 1, Total Completed: 0, Total Errors: 0] [ManageIUInstaller has received a changeCompleted Event: COMPLETED] [Total Ops: 1,Total Completed: 1,Total Errors: 0] --> ChangeManager Touchpoint and CE Thread completed. Status of CM Operations Java Custom Action StartTime: 8/12/05 4:53 PM EndTime: 8/12/05 4:53 PM CMOP: Delete Errors: [] State: COMPLETED
Note that the primary operation is delete, and the operation is being performed on the RootIU. The change management operation indicates that the Java custom action IU has successfully been deleted.
The IU view panel is automatically refreshed at the completion of each action invoked by the control panel.
Installing the Java Custom Action sample yields the following output:
----------------------------------------------------- JAVACUSTOMACTION ----------------------------------------------------- Listing Requested IUInstances. Number of instances = 2 Instance 1 Type : Software Instance Version : 1.2 Subtype : IU Name : Java Custom Action Version : 1.2 UUID : 7F48A5596BF97B1676D7AD8DB5634BD1 Instance 2 Type : Software Instance Version : 1.2 Subtype : Root IU Name : Java Custom Action Package Version : 1.2 UUID : CC05DC31804627BBA6E6661C48BF1A81
The information shown in the View IU panel has been filtered and formatted for the Integrated Solutions Console panel . The complete raw information can be observed by using the command line
<SI_SAMPLES_HOME>/bin/listIU.bat(sh)
and observing the results in the listIU.out file in the same bin directory.
Uninstalling the Java Custom Action sample yields an output with no JAVACUSTOMACTION entries since they have been removed.
The View IU panel is empty.
The Java Custom Action sample is controlled by installing it and uninstalling it. In the Control panel for the Java Custom Action, click Install Sample to begin the sample operation. The sample runs to completion automatically, periodically refreshing the console panels during the process. After installation has completed, the following panels on the console are refreshed as a result of the installation:
After the sample is installed, the Install Sample link is disabled, and the Un-install Sample link is enabled.
In the control panel for the Java Custom Action, click Un-install Sample to remove the sample. The sample runs through the uninstall process and completes automatically. After the uninstall has completed, the following panels on the console are refreshed: as a result of the installation:
After the sample is uninstalled, the Un-install Sample link is disabled, and the autonomic manager Install Sample link is enabled. Uninstalling the sample does not remove the new directory (jca_test) and the new text file (jca_test.txt) since a complete uninstall artifact has not been provided as part of this sample. Refer to the Family sample for an un-installation artifact demonstration.
The sample can be rerun at any time by performing another install. If the sample is currently installed (Install Sample link is not enabled), click Un-install Sample to remove the sample and then click Install Sample.
The Lifecycle sample was developed to demonstrate a full software life cycle of a solution offering for developers and software package authors utilizing Solution Installation and Deployment technologies. It will demonstrate the following typical life cycle actions:
The sample consists of four Solution Install packages (.zip files) which contain the files to be installed at each phase of the life cycle, and the XML files that define the installation characteristics of each part of the life cycle being demonstrated
The user interacts directly with the sample by:
This scenario demonstrates the full life cycle of a software offering based on members of a family. The entire scenario consists of the following four packages:
Each package is broken down in Figure 5.
Figure 5. Family package layout
In summary, the base 1.2.0 package contains two root level features (Parents and Children), one of which (Parents) contains two subfeatures (Dad and Mom). Children, Dad, and Mom features each contain one IU. The objective is to demonstrate a path that will get to the 2.0.0 level where we would have the same number of features, but with an additional IU as part of Children, while also introducing a new feature available for installation.
To better correlate this life cycle sample with a real product scenario, consider the Family IU to be a product with a set of features (optional components of that product). This product is installed and configured as part of an initial deployment. Later, a fix is required to one component of the product. The fix is installed but it later turns out to have some negative effects and is removed. Sometime later, a fixpack (incremental update) becomes available for the product. The fixpack happens to include some new function (maybe a new language pack). The fixpack is applied to the product. Again, configuration might be required and in our case, we assume some migration of data was needed with the fixpack. At some point later, a complete refresh is available for the product. The refresh is applied and each of the components is replaced. Finally, the product is no longer needed and is uninstalled.
The sample can be run using the Integrated Solutions Console found in the Autonomic Computing Toolkit, or from the command line. The Solution Installation and Deployment Samples Scenario bundle contains the Lifecycle sample, and requires that the Integrated Solutions Console be installed.
The Lifecycle sample uses the following control links to operate the sample:
The links are only enabled according to how a typical software product life cycle might occur. For example, the Family1.2.0 uninstall link will not be enabled until the Family1.2.0 base has been installed. Not only does this give control over how the sample can be executed, but it also provides alternate paths that the life cycle might take. This allows the user to study a variety of path options.
Other than enabling and disabling the various control links, this control panel does not change during the operation of the sample.
The sample can be executed using the Integrated Solution Console found in the Autonomic Computing Toolkit, or from the command line. The Solution Installation and Deployment Samples Scenario bundle contains the Lifecycle sample, and requires that the Integrated Solution Console be installed.
In addition to be installed, the Integration Solutions Console must be activated before control of the sample can begin. Navigate to the Lifecycle Control panel to begin running the sample.
The Family full life cycle sample uses the following descriptor files:
In addition, this sample provides a link that displays the complete list of descriptors and the relationships between them in a content specific layout.
The Deployment Descriptor panel remains unchanged throughout the course of the sample. The links are always enabled, independent of which part of the life cycle sample is being executed.
The Log View panel is used to display the events and actions taken during the install and uninstall of the Family full life cycle sample. It is dynamically updated as each control link is invoked from the Control panel and the packages of the Family product applied. The exact content of the Log View panel will be discussed in the next section that describes each phase of the Family full life cycle sample.
The IU View panel is used to verify each phase of the Family full life cycle sample. It is dynamically updated as each control link is invoked from the Control panel. The exact content of the IU View panel varies depending on which phase of the Family full life cycle sample is being executed, and is discussed in the next section.
The information shown in the View IU panel has been filtered and formatted for the Integrated Solutions Console panel. The complete raw information can be observed by using the command line:
<SI_SAMPLES_HOME>/bin/listIU.bat(sh)
and observing the results in the listIU.out file in the same bin directory.
This section describes how to run the Family full life cycle sample. The sample can be run using the Integrated Solutions Console or a command line interface. For each phase of the Family full life cycle sample, both methods will be described.
Starting the Sample
The Family full life cycle sample is controlled by installing several packages representing a typical product Family full life cycle. Since this sample has several installations, and some are optional, several paths exist for running the sample. We will cover one possible path described below. The user can experiment with other paths and observe the differences in behavior.
During each step of the life cycle installation, the following panels on the console are automatically refreshed:
A base installable unit is a software package that contains a major release of a product. This type of software package is used for the initial deployment of the software. This type of IU modifies the version, release, and modification parts of the overall version.
The deployment descriptor that describes the installation characteristics of the base package is available in the Samples Descriptors panel in the Work Area. To access the descriptor, click base/packagedIU.xml. This descriptor references other deployment descriptors in the same base package called install artifacts. Install artifacts are used to create a new instance of an IU or to update an existing instance of an IU. Actions that are defined in an Install artifact refer to bundled files in the base software package.
Click View the complete list of descriptors on the Descriptor panel to view the following three install artifacts used in the base package:
The Family 1.2.0 base package is installed using the Integrated Solutions Console by selecting Install V1.2.0. Installing the Lifecycle Family 1.2.0 base package yields the following Log View panel output, and indicates that three IUs were successfully created (Daughter, Mom and Dad):
--> ManageIUInstaller started Primary Operation is: CREATE --> Constructing MediaReader. URI is: Family_1.2.0_Base.zip --> Running Parse Deployment Descriptor via Dependency Checker --> Getting Target Hosting Environment. --> Running checkSystem... --> Executing ChangeManager Change() method [ManageIUInstaller has received a change Event: SUBMITTED ] [Total Ops: 0, Total Completed: 0, Total Errors: 0] [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 3, Total Completed: 0, Total Errors: 0] --> ChangeManager Change() method returned to calling program (ManageIU) [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 3, Total Completed: 0, Total Errors: 0] [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 3, Total Completed: 1, Total Errors: 0] [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 3, Total Completed: 2, Total Errors: 0] [ManageIUInstaller has received a changeCompleted Event: COMPLETED] [Total Ops: 3,Total Completed: 3,Total Errors: 0] --> ChangeManager Touchpoint and CE Thread completed. Status of CM Operations Daughter IU StartTime: 8/12/05 4:57 PM EndTime: 8/12/05 4:57 PM CMOP: Create Errors: [] State: COMPLETED Mom IU StartTime: 8/12/05 4:57 PM EndTime: 8/12/05 4:57 PM CMOP: Create Errors: [] State: COMPLETED Dad IU StartTime: 8/12/05 4:57 PM EndTime: 8/12/05 4:57 PM CMOP: Create Errors: [] State: COMPLETED
Installing the Family 1.2.0 base yields the following View IU panel output and represents the installed instances of Package 1 (Family 1.2.0 Base ) shown in Figure 5:
----------------------------------------------------- FAMILY ----------------------------------------------------- Listing Requested IUInstances. Number of instances = 8 Instance 1 Type : Software Instance Version : 1.2.0 Subtype : IU Name : Dad IU Version : 1.2.0 UUID : 991974510BA426FE1F53841402351130 Instance 2 Type : Software Instance Version : 1.2.0 Subtype : IU Name : Mom IU Version : 1.2.0 UUID : 991974510BA426FE1F53841402351129 Instance 3 Type : Software Instance Version : 1.2.0 Subtype : IU Name : Daughter IU Version : 1.2.0 UUID : 991974510BA426FE1F53841402351128 Instance 4 Type : Software Instance Version : 1.2.0 Subtype : Root IU Name : Family RootIU Version : 1.2.0 UUID : 991974510BA426FE1F53841402351114 Instance 5 Type : Feature Instance Name : Children_Feature RootIU UUID : 991974510BA426FE1F53841402351114 Instance 6 Type : Feature Instance Name : Dad_Feature RootIU UUID : 991974510BA426FE1F53841402351114 Instance 7 Type : Feature Instance Name : Mom_Feature RootIU UUID : 991974510BA426FE1F53841402351114 Instance 8 Type : Feature Instance Name : Parents_Feature RootIU UUID : 991974510BA426FE1F53841402351114
In order to complete the installation of the 1.2.0 base package, an initial configuration must be executed. InitialConfig artifacts are used to define actions that will transition a newly created instance of an IU from the Created state to the Usable state.
ClickView the complete list of descriptors on the Descriptor panel to view the following three InstallConfig artifacts used in the base package:
The Family 1.2.0 base package is configured using the Integrated Solutions Console by selecting Configure base for Family 1.2.0 in the Control panel.
Selecting the Family 1.2.0 Configure base link yields the following Log View output:
--> ManageIUInstaller started Primary Operation is: INIT_CONFIG RootTypeID target is: RootIUTypeID[991974510BA426FE1F53841402351114,1.2.0] --> Running checkSystem... --> Executing ChangeManager Change() method [ManageIUInstaller has received a change Event: SUBMITTED ] [Total Ops: 0, Total Completed: 0, Total Errors: 0] [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 3, Total Completed: 0, Total Errors: 0] --> ChangeManager Change() method returned to calling program (ManageIU) [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 3, Total Completed: 0, Total Errors: 0] [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 3, Total Completed: 1, Total Errors: 0] [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 3, Total Completed: 2, Total Errors: 0] [ManageIUInstaller has received a changeCompleted Event: COMPLETED] [Total Ops: 3,Total Completed: 3,Total Errors: 0] --> ChangeManager Touchpoint and CE Thread completed. Status of CM Operations Daughter IU StartTime: 8/12/05 4:59 PM EndTime: 8/12/05 4:59 PM CMOP: InitialConfig Errors: [] State: COMPLETED Mom IU StartTime: 8/12/05 4:59 PM EndTime: 8/12/05 4:59 PM CMOP: InitialConfig Errors: [] State: COMPLETED Dad IU StartTime: 8/12/05 4:59 PM EndTime: 8/12/05 4:59 PM CMOP: InitialConfig Errors: [] State: COMPLETED
Note that the primary operation is init_config and is being applied to the Root IU. The change management operations indicates that IUs Daughter, Dad, and Mom have the status of Initial Configure. These are the IUs that compose the Family 1.2.0 base package.
Selecting the Family 1.2.0 Configure base base installation yields the identical View IU panel output l, so it is not repeated here.
Software fixes are a common occurrence in a product life cycle. The fix included in the Family Full Lifecycle sample demonstrates a situation where the "Daughter IU" from the 1.2.0 base installation needs a fix to be applied.
A fix installable unit is a software package that contains fixes that have yet to be included in either a full update IU or incremental update IU. This type of IU modifies the level of software installed, but it does not modify the version, release, or modification parts of the overall version.
The deployment descriptor that describes the installation characteristics of the fix package is available in the Samples Descriptors panel in the Work Area, and named fix/packagedIU.xml. This descriptor also references other deployment descriptors in the same fix package.
Click View the complete list of descriptors on the Descriptor panel to view the following FixInstallArtifacts descriptor used in the fix package:
DaughterFixInstallArtifact.xml
The 1.2.0 base fix is installed using the Integrated Solutions Console by selecting Install Fix for Family 1.2.0 in the Control panel. The Install Fix link was enabled after the successful installation of the 1.2.0 base package.
Installing the Lifecycle Family 1.2.0 Fix package yields the following Log View panel output, indicating the Daughter IU has been updated:
--> ManageIUInstaller started Primary Operation is: UPDATE --> Constructing MediaReader. URI is: Daughter_1.2.0_Fix.zip --> Running Parse Deployment Descriptor via Dependency Checker --> Running checkSystem... --> Executing ChangeManager Change() method [ManageIUInstaller has received a change Event: SUBMITTED ] [Total Ops: 0, Total Completed: 0, Total Errors: 0] [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 1, Total Completed: 0, Total Errors: 0] --> ChangeManager Change() method returned to calling program (ManageIU) [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 1, Total Completed: 0, Total Errors: 0] [ManageIUInstaller has received a changeCompleted Event: COMPLETED] [Total Ops: 1,Total Completed: 1,Total Errors: 0] --> ChangeManager Touchpoint and CE Thread completed. Status of CM Operations Daughter IU StartTime: 8/12/05 5:04 PM EndTime: 8/12/05 5:04 PM CMOP: Update Errors: [] State: COMPLETED
Installing the Family 1.2.0 fix package yields the following additional IU output from the 1.2.0 base IU list and represents the installed instances of Package 1 (Family 1.2.0 Base) shown in Figure 5:
----------------------------------------------------- FAMILY ----------------------------------------------------- Listing Requested IUInstances. Number of instances = 11 Instance 1 Type : Software Instance Version : 1.2.0 Subtype : IU Name : Dad IU Version : 1.2.0 UUID : 991974510BA426FE1F53841402351130 Instance 2 Type : Software Instance Version : 1.2.0 Subtype : IU Name : Mom IU Version : 1.2.0 UUID : 991974510BA426FE1F53841402351129 Instance 3 Type : Software Instance Version : 1.2.0 Subtype : IU Name : Daughter IU Version : 1.2.0 UUID : 991974510BA426FE1F53841402351128 Instance 4 Type : Software Instance Version : 1.2.0 Subtype : Root IU Name : Family RootIU Version : 1.2.0 UUID : 991974510BA426FE1F53841402351114 Instance 5 Type : Feature Instance Name : Children_Feature RootIU UUID : 991974510BA426FE1F53841402351114 Instance 6 Type : Feature Instance Name : Dad_Feature RootIU UUID : 991974510BA426FE1F53841402351114 Instance 7 Type : Feature Instance Name : Mom_Feature RootIU UUID : 991974510BA426FE1F53841402351114 Instance 8 Type : Feature Instance Name : Parents_Feature RootIU UUID : 991974510BA426FE1F53841402351114 Instance 9 Type : Feature Instance Name : Children_Feature RootIU UUID : 991974510BA426FE1F53841402351114 Instance 10 Type : Fix Instance Name : Daughter_IU_1.2.0_Fix RootIU UUID : 991974510BA426FE1F53841402351114 Instance 11 Type : Fix Instance Name : Family_RootIU_1.2.0_Daughter_Fix_1 RootIU UUID : 991974510BA426FE1F53841402351114
Note that the primary operation is Update. The package that has been applied is Daughter_1.2.0_fix.zip. The change management operation status is Completed, which indicates that the IU Daughter was successfully updated. The fix has only been applied to the single IU named Daughter.
You will notice a couple of things in the output that are different from the previous listIU output. First, you see that there are two fixes registered: one for the RootIU and one for the Daughter_IU. Also, you will notice that the number of features has doubled. This is because the fix needs its own copy of the features for Solution Installation internal workings, so this is normal behavior.
It is not uncommon that a fix applied to a product does not work or causes undesirable side effects. This phase of the life cycle sample demonstrates removing a previously applied fix.
The Family Lifecycle 1.2.0 fix package is uninstalled using the Integrated Solutions Console by selecting Un-install Fix for Family 1.2.0 in the Control panel.
The Family Lifecycle 1.2.0 Un-install Fix yields the following Log View output:
--> ManageIUInstaller started Primary Operation is: UNDO --> Running checkSystem... --> Executing ChangeManager Change() method [ManageIUInstaller has received a change Event: SUBMITTED ] [Total Ops: 0, Total Completed: 0, Total Errors: 0] [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 1, Total Completed: 0, Total Errors: 0] --> ChangeManager Change() method returned to calling program (ManageIU) [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 1, Total Completed: 0, Total Errors: 0] [ManageIUInstaller has received a changeCompleted Event: COMPLETED] [Total Ops: 1,Total Completed: 1,Total Errors: 0] --> ChangeManager Touchpoint and CE Thread completed. Status of CM Operations Inst. ID: InstanceID[Fix,Daughter_IU_1.2.0_Fix,mrid:http://w3.ibm.com/namespaces/2003/OS_componentTypes:Operating_System,null,FAMILY] StartTime: 8/12/05 5:06 PM EndTime: 8/12/05 5:06 PM CMOP: Undo Errors: [] State: COMPLETED
Note that the primary operation is Undo, and the change management operation for Daughter_IU_1.2.0_Fix has been completed successfully.
Applying the Family 1.2.0 Un-install Fix yields the same output produced by the Family 1.2.0 base installation. This verifies that the fix rollback has occurred successfully and restored the 1.2.0 base back to its original configuration. See the IU List for the 1.2.0 Base install for details.
For the remaining steps, you can apply the fix again if you like. However, for simplicity of demonstration, we will keep the fix removed as we move forward with the sample.
The incremental update in this sample represents a scheduled update to the base product. In our incremental update, we are going to update the Daughter_IU.
An Incremental Update Installable Unit is a software package that contains the minor release only of a product. This type of IU modifies the version, release, and modification parts of the overall version.
The deployment descriptor that describes the installation characteristics of the incremental update package is available in the Samples Descriptors panel in the Work Area, and named incremental/packagedIU.xml. This descriptor references other deployment descriptors in the same base package called install artifacts. Install artifacts are used to create a new instance of an IU or to update an existing instance of an IU. Actions that are defined in an Install artifact refer to bundled files in the incremental update software package.
Click View the complete list of descriptors on the Descriptor panel to view the following installation artifacts used in the incremental update package:
The Family 1.2.0 Incremental update package is installed using the Integrated Solutions Console by selecting Install Incremental Update for Family 1.2.0 in the Control panel.
Installing the Lifecycle 1.2 .0Install Incremental Update (with the fix removed) yields the following Log View panel output:
--> ManageIUInstaller started Primary Operation is: UPDATE --> Constructing MediaReader. URI is: Family_1.5.0_Incremental.zip --> Running Parse Deployment Descriptor via Dependency Checker --> Running checkSystem... --> Executing ChangeManager Change() method [ManageIUInstaller has received a change Event: SUBMITTED ] [Total Ops: 0, Total Completed: 0, Total Errors: 0] [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 1, Total Completed: 0, Total Errors: 0] --> ChangeManager Change() method returned to calling program (ManageIU) [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 1, Total Completed: 0, Total Errors: 0] [ManageIUInstaller has received a changeCompleted Event: COMPLETED] [Total Ops: 1,Total Completed: 1,Total Errors: 0] --> ChangeManager Touchpoint and CE Thread completed. Status of CM Operations Daughter IU StartTime: 8/12/05 5:08 PM EndTime: 8/12/05 5:08 PM CMOP: Update Errors: [] State: COMPLETED
Note that the primary operation is Update, and the update package being applied is Family_1.5.0_incremental.zip. The change management operations indicate that the IU Daughter has been successfully updated. The incremental update package contains a single IU: Daughter update.
Installing the Family 1.2 Incremental Update package yields the following View IU panel output:
----------------------------------------------------- FAMILY ----------------------------------------------------- Listing Requested IUInstances. Number of instances = 11 Instance 1 Type : Software Instance Version : 1.5.0 Subtype : IU Name : Daughter IU Version : 1.5.0 UUID : 991974510BA426FE1F53841402351128 Instance 2 Type : Software Instance Version : 1.2.0 Subtype : IU Name : Dad IU Version : 1.2.0 UUID : 991974510BA426FE1F53841402351130 Instance 3 Type : Software Instance Version : 1.2.0 Subtype : IU Name : Mom IU Version : 1.2.0 UUID : 991974510BA426FE1F53841402351129 Instance 4 Type : Software Instance Version : 1.2.0 Subtype : IU Name : Daughter IU Version : 1.2.0 UUID : 991974510BA426FE1F53841402351128 Instance 5 Type : Software Instance Version : 1.2.0 Subtype : Root IU Name : Family RootIU Version : 1.2.0 UUID : 991974510BA426FE1F53841402351114 Instance 6 Type : Software Instance Version : 1.5.0 Subtype : Root IU Name : Family RootIU Version : 1.5.0 UUID : 991974510BA426FE1F53841402351114 Instance 7 Type : Feature Instance Name : Children_Feature RootIU UUID : 991974510BA426FE1F53841402351114 Instance 8 Type : Feature Instance Name : Dad_Feature RootIU UUID : 991974510BA426FE1F53841402351114 Instance 9 Type : Feature Instance Name : Mom_Feature RootIU UUID : 991974510BA426FE1F53841402351114 Instance 10 Type : Feature Instance Name : Parents_Feature RootIU UUID : 991974510BA426FE1F53841402351114 Instance 11 Type : Feature Instance Name : Children_Feature RootIU UUID : 991974510BA426FE1F53841402351114
As with previous versions of this output, you see that the number of features have doubled to indicated their association with the update. Also, you see updated IUs, the Root IUs; Family and Daughter are listed twice at versions 1.2.0 and 1.5.0. This illustrates how Solution Installation and Deployment keeps track of updates, the original IU plus the updated IU. Note the differences in the full update section.
Migrate the Family 1.2.0 incremental update package by selecting the Migrate Update link for Family 1.2.0 in the control panel. The Incremental/packagedIU.xml descriptor file references Migrate artifacts descriptors in the incremental update package. Migrate artifacts are used to define actions that will transition an updated instance of an IU from the Created state to the Usable state.
Use the View the complete list of descriptors link on the Descriptor panel to view the following Migrate artifacts used in the incremental update package. Selecting the Migrate Update link yields the following Log View output:
--> ManageIUInstaller started Primary Operation is: MIGRATE RootTypeID target is: RootIUTypeID[991974510BA426FE1F53841402351114,1.5.0] --> Running checkSystem... --> Executing ChangeManager Change() method [ManageIUInstaller has received a change Event: SUBMITTED ] [Total Ops: 0, Total Completed: 0, Total Errors: 0] [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 1, Total Completed: 0, Total Errors: 0] --> ChangeManager Change() method returned to calling program (ManageIU) [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 1, Total Completed: 0, Total Errors: 0] [ManageIUInstaller has received a changeCompleted Event: COMPLETED] [Total Ops: 1,Total Completed: 1,Total Errors: 0] --> ChangeManager Touchpoint and CE Thread completed. Status of CM Operations Daughter IU StartTime: 8/12/05 5:10 PM EndTime: 8/12/05 5:10 PM CMOP: Migrate Errors: [] State: COMPLETED
The primary operation is Migrate, and is being applied to the root IU. The change management operation indicates that the IU Daughter has been migrated.
Having demonstrated a fix and an incremental update, it's time to apply a full update to this scenario. This full update will take the existing 1.2.0 base and upgrade it to the 2.0.0 version of the product.
A Full Update Installable Unit is a software package that contains the major release of a product plus a minor release (maintenance release or service pack). During installation, either the minor release is deployed or both the major release and the minor release are deployed. This type of software package is used for the initial deployment of the software or for the upgrade pf previously deployed software. This type of IU modifies the version, release, and modification parts of the overall version.
The deployment descriptor that describes the installation characteristics of the full update package is available in the Samples Descriptors panel in the Work Area, and named fullupdate/packagedIU.xml. This descriptor references other deployment descriptors in the same full update package (called install artifacts).
Use the View the complete list of descriptors link on the Descriptor panel to view the following install artifacts used in the full update package:
The Family 2.0.0 Full Update package is installed using the Integrated Solutions Console by selecting the Install Full Update V 2.0.0 link from the Control panel.
Installing the Family Lifecycle 2.0.0 Full Update package yields the following Log View output:
--> ManageIUInstaller started Primary Operation is: UPDATE --> Constructing MediaReader. URI is: Family_2.0.0_Base.zip --> Running Parse Deployment Descriptor via Dependency Checker --> Running checkSystem... --> Executing ChangeManager Change() method [ManageIUInstaller has received a change Event: SUBMITTED ] [Total Ops: 0, Total Completed: 0, Total Errors: 0] [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 3, Total Completed: 0, Total Errors: 0] --> ChangeManager Change() method returned to calling program (ManageIU) [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 3, Total Completed: 0, Total Errors: 0] [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 3, Total Completed: 1, Total Errors: 0] [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 3, Total Completed: 2, Total Errors: 0] [ManageIUInstaller has received a changeCompleted Event: COMPLETED] [Total Ops: 3,Total Completed: 4,Total Errors: 0] --> ChangeManager Touchpoint and CE Thread completed. Status of CM Operations Daughter IU StartTime: 8/12/05 5:13 PM EndTime: 8/12/05 5:13 PM CMOP: Update Errors: [] State: COMPLETED Mom IU StartTime: 8/12/05 5:13 PM EndTime: 8/12/05 5:13 PM CMOP: Update Errors: [] State: COMPLETED Dad IU StartTime: 8/12/05 5:13 PM EndTime: 8/12/05 5:13 PM CMOP: Update Errors: [] State: COMPLETED
Note that the primary operation is Update, and the package being applied is Family_2.0.0_base.zip. The change management operations indicate IUs Daughter, Dad, and Mom have been successfully updated.
The output from the View IU panel shows the RootIU, four IUs, and four features as being registered; all at version 2.0.0:
----------------------------------------------------- FAMILY ----------------------------------------------------- Listing Requested IUInstances. Number of instances = 9 Instance 1 Type : Software Instance Version : 2.0.0 Subtype : IU Name : Mom IU Version : 2.0.0 UUID : 991974510BA426FE1F53841402351129 Instance 2 Type : Software Instance Version : 2.0.0 Subtype : IU Name : Dad IU Version : 2.0.0 UUID : 991974510BA426FE1F53841402351130 Instance 3 Type : Software Instance Version : 2.0.0 Subtype : IU Name : Daughter IU Version : 2.0.0 UUID : 991974510BA426FE1F53841402351128 Instance 4 Type : Software Instance Version : 2.0.0 Subtype : Root IU Name : Family RootIU Version : 2.0.0 UUID : 991974510BA426FE1F53841402351114 Instance 5 Type : Feature Instance Name : Children_Feature RootIU UUID : 991974510BA426FE1F53841402351114 Instance 6 Type : Feature Instance Name : Dad_Feature RootIU UUID : 991974510BA426FE1F53841402351114 Instance 7 Type : Feature Instance Name : Mom_Feature RootIU UUID : 991974510BA426FE1F53841402351114 Instance 8 Type : Feature Instance Name : Parents_Feature RootIU UUID : 991974510BA426FE1F53841402351114
Notice that each of the IUs has now been replaced with a single instance at version 2.0.0. Solution Install does not remember full updates as the original plus some delta. It is a complete replacement of the IU.
Migrate the Family 2.0.0 Full Update by selecting Migrate update link for Family 2.0.0 in the Control panel. The fullupdate/packagedIU.xml descriptor references Migrate artifact descriptors in the full update package. Migrate artifacts are used to define actions that will transition an updated instance of an IU from the Created state to the Usable state.
Use the Complete list of descriptors link on the Descriptor panel to view the following Migrate artifact usedin the full update package:
Migrating the Family Lifecycle 2.0.0 Migrate Full Update yields the following Log View panel output:
--> ManageIUInstaller started Primary Operation is: MIGRATE RootTypeID target is: RootIUTypeID[991974510BA426FE1F53841402351114,2.0.0] --> Running checkSystem... --> Executing ChangeManager Change() method [ManageIUInstaller has received a change Event: SUBMITTED ] [Total Ops: 0, Total Completed: 0, Total Errors: 0] [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 3, Total Completed: 0, Total Errors: 0] --> ChangeManager Change() method returned to calling program (ManageIU) [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 3, Total Completed: 0, Total Errors: 0] [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 3, Total Completed: 1, Total Errors: 0] [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 3, Total Completed: 2, Total Errors: 0] [ManageIUInstaller has received a changeCompleted Event: COMPLETED] [Total Ops: 3,Total Completed: 3,Total Errors: 0] --> ChangeManager Touchpoint and CE Thread completed. Status of CM Operations Dad IU StartTime: 8/12/05 5:14 PM EndTime: 8/12/05 5:14 PM CMOP: Migrate Errors: [] State: COMPLETED Daughter IU StartTime: 8/12/05 5:14 PM EndTime: 8/12/05 5:14 PM CMOP: Migrate Errors: [] State: COMPLETED Mom IU StartTime: 8/12/05 5:14 PM EndTime: 8/12/05 5:14 PM CMOP: Migrate Errors: [] State: COMPLETED
Note that the primary operation is Migrate, and is being applied to the Root IU. The change management operation indicates that the IUs Daughter, Dad, and Mom have been migrated.
At the end of the Lifecycle sample, the product goes end-of-life and is removed. The full update descriptor references Uninstall artifact descriptors in the full update package. Un-install artifacts are used with a Delete operation to define actions that will remove an instance of IU or fix.
Click View the complete list of descriptors on the Descriptor panel to view the Uninstall artifacts used in the full update package.
To un-install the Lifestyles 2.0.0 base, select Un-install V2.0.0 on the Integrated Solution Console control panel for the 2.0.0 base.
Un-installing the Family Lifecycle 2.0.0 package yields the following Log View output:
--> ManageIUInstaller started Primary Operation is: DELETE RootTypeID target is: RootIUTypeID[991974510BA426FE1F53841402351114,2.0.0] --> Running checkSystem... --> Executing ChangeManager Change() method [ManageIUInstaller has received a change Event: SUBMITTED ] [Total Ops: 0, Total Completed: 0, Total Errors: 0] [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 3, Total Completed: 0, Total Errors: 0] --> ChangeManager Change() method returned to calling program (ManageIU) [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 3, Total Completed: 0, Total Errors: 0] [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 3, Total Completed: 1, Total Errors: 0] [ManageIUInstaller has received a change Event: EXECUTING ] [Total Ops: 3, Total Completed: 2, Total Errors: 0] [ManageIUInstaller has received a changeCompleted Event: COMPLETED] [Total Ops: 3,Total Completed: 3,Total Errors: 0] --> ChangeManager Touchpoint and CE Thread completed. Status of CM Operations Dad IU StartTime: 8/12/05 5:16 PM EndTime: 8/12/05 5:16 PM CMOP: Delete Errors: [] State: COMPLETED Mom IU StartTime: 8/12/05 5:16 PM EndTime: 8/12/05 5:16 PM CMOP: Delete Errors: [] State: COMPLETED Daughter IU StartTime: 8/12/05 5:16 PM EndTime: 8/12/05 5:16 PM CMOP: Delete Errors: [] State: COMPLETED
Note that the primary operation is Delete, and is being applied to the Root IU. The change management operations indicate that the IUs Daughter, Dad, and Mom have been successfully deleted.
The List IU panel is blank indicating that all Lifecycle IUs have been removed. This completes the software life cycle sample.
The sample can be rerun at anytime by performing another install. If the sample is currently installed (Family 1.2.0 Install V1.2.0 link or Family 2.0.0 Install Full Update V2.0.0 link is not enabled), click either the Family 1.2.0 Un-install V1.2.0 link or the Family 2.0.0 Un-install V 2.0.0 link to remove the sample and enable the Install links.
This section provides details on how you can use the command line interface to demonstrate the Solution Installation and Deployment samples. Running the samples using the command line does not require the Integrated Solutions Console to be installed.
There are two samples - Java Custom Action and Family Full Lifecycle. See the previous sections on using the console for additional details on the samples operation. All the artifacts for the samples are present in the
<SI_SCENARIO_HOME>/samples/<Sample_Name>
folder. The following terms are used in the command specified in this doc. These terms should be replaced with appropriate value, as defined, while executing the samples.
Please execute the commands below to execute and view the samples. (All the commands are one line commands only) Please note the following:
The java custom action sample is demonstrated by performing an installation and, once the sample is understood, uninstalling it.
To install the java custom action sample, issue the following installation command:
install.bat(sh) JCA_DIR JAVACUSTOMACTION java_custom_action.zip
To delete the java custom action sample, issue the following command:
delete.bat(sh) JCA_DIR JAVACUSTOMACTION RootIUTypeID[cc05dc31804627bba6e6661c48bf1a81,1.2]
The location where the artifacts for this sample will be copied is defined in the properties file present in FAMILY_DIR. Please update all the properties files with the (same) value where you want the artifacts to be copied. To identify the property to be updated, look for a value having #installLocation in its name. You may change this location, if you want. After executing each command, you may go and view the artifacts in the location defined in the properties file. To explore this sample completely, please execute the commands in the order in which they are specified here. (Do not skip any command, unless this is suggested)
install.bat(sh) FAMILY_DIR FAMILY Family_1.2.0_Base.zip Response_1.2.0.properties
configure.bat(sh) FAMILY_DIR FAMILY RootIUTypeID[991974510ba426fe1f53841402351114,1.2.0] Response_1.2.0_init.properties
You may skip this step and move directly to the incremental fix.
fix.bat(sh) FAMILY_DIR FAMILY Daughter_1.2.0_Fix.zip Response_1.2.0_fix.properties
You may retain the fix and move to next step if you want.
rollback.bat(sh) FAMILY_DIR FAMILY RootIUTypeID[991974510ba426fe1f53841402351114,Family_RootIU_1.2.0_JudyDaughter_Fix_1] Response_1.2.0_fix.properties
migrate.bat(sh) FAMILY_DIR FAMILY RootIUTypeID[991974510ba426fe1f53841402351114,1.5.0] Response_1.5.0.properties
Do not delete the base if you want to upgrade the sample from v1.2.0 to v2.0.0.
Please note that this command will remove the fix and the incremental update, if they are present.
delete.bat(sh) FAMILY_DIR FAMILY RootIUTypeID[991974510ba426fe1f53841402351114,1.2.0] Response_1.2.0.properties
update.bat(sh) FAMILY_DIR FAMILY Family_2.0.0_Base.zip Response_2.0.0.properties
migrate.bat(sh) FAMILY_DIR FAMILY RootIUTypeID[991974510ba426fe1f53841402351114,2.0.0] Response_2.0.0_migrate.properties
delete.bat(sh) FAMILY_DIR FAMILY RootIUTypeID[991974510ba426fe1f53841402351114,2.0.0] Response_2.0.0.properties
The Integrated Solutions Console component plug-in has been desig
