![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Software components go through various stages during their lives. Applications are installed, go through maintenance, get upgraded to higher versions, and so on. Solution Install, a core technology that enables software solutions to be deployed and supported with reduced human interaction, offers various change requests that transition an application from one stage to another.
This article explains how the different Solution Install change requests affect an application, and offers some caveats you should consider before trying to perform a new change request. Using our example software application, Sample App, we'll examine the current stage of Sample App and explore all the possible change requests that can be performed at that stage. For example, when an application is installed at its initial version, what type of change request can now be performed, and what caveats exist? Are there any differences when an application is installed but has had a fix applied?
Table 1 lists the change requests that Solution Install offers.
Table 1. Change requests
| Change request | Description |
|---|---|
| Create | Installs a software package and additional features |
| Initial Configure | Applies the initial configuration to software that is in the Created state, causing the transition to the Usable state |
| Configure | Applies artifacts associated with configuration units |
| Update (Fix) | Applies a fix to existing software |
| Update (Incremental) | Supersedes existing software |
| Update (Full) | Upgrades existing software |
| Migrate | Applies configuration to software that is in the Updated state, causing the transition to the Usable state |
| Undo | Undoes an applied fix or incremental update |
| Delete | Uninstalls a software package and individual features |
Each section in this article, listed below, represents the current stage of an application. The article walks you through what change requests you can use when:
- A software application is not installed
- Sample App 1.0 is installed
- Sample App Fix1 is applied to Sample App 1.0
- Sample App 1.0 has been incrementally updated
- A full update package, Sample App 2.0, is installed
- Sample App 1.0 has been fixed, then incrementally updated by Sample App 1.1
- Sample App 1.0 has been fixed, incrementally updated, then fixed again by a superseding fix
- Sample App 1.0 has been fixed, then fixed again with a non-superseding fix
Given the current stage of your application, find the corresponding main heading to see what change requests can be performed on the application. For example, if you want to install additional features for an application that has already been incrementally updated, start by going to Sample App 1.0 has been incrementally updated by Sample App 1.1, then go to the subheading To install additional features.
Each section has a diagram labeled with Yes, in green, or No, in red, to indicate which change requests are allowed by Solution Install in the given situation. Each section also includes subheadings that represent a desired stage for the application, if applicable, for how to:
- Install a software package for the first time
- Install additional features
- Configure the application in a non-repeatable manner
- Apply a fix to an installed application
- Supersede an application with a newer version
- Upgrade an application to a newer version
- Remove individual features
- Uninstall an entire application
- Configure newly installed features in a non-repeatable manner
- Apply additional fixes to an installed application
- Undo an applied fix
- Apply fixes to a superseding application
- Supersede a superseding application with a newer version
- Configure a recently applied update
- Undo a superseding application
- Configure installable units (IU) from a full update Installable Unit Deployment Descriptors (IUDD) in a non-repeatable manner
- Undo an upgrade
- Undo a non-superseding fix
A sidebar to the right of each subsection summarizes what software is installed after each change request.
When a software application is not installed
If you're checking whether a particular application is installed on a user's machine and you discover that it is not, there are a couple of change requests you can perform using Solution Install. Figure 1 shows which possible change requests can be performed.
Figure 1. Clean system
To install a software package for the first time
To install an application for the first time, the Create request must be performed. The Create request can be used for the initial installation of base or full update Installable Unit Deployment Descriptors (IUDD).
Assuming that Sample App 1.0 and Sample App 2.0 are available for installation, and neither are installed on the system, the base package (Sample App 1.0) or the full update package (Sample App 2.0) can be installed. Do this by performing a Create request on the desired version of Sample App, if there are no previous versions of Sample App already installed.
If InitConfig or Config artifacts are present in the IUDD, see To configure the application in a non-repeatable manner.
At this point, Sample App 1.0 has been installed on the system. Figure 2 indicates, by Yes or No, what possible change requests can be performed.
Figure 2. Sample App 1.0
To install additional features
Even though Sample App 1.0 is already installed, the Create request can be performed to add additional features that were not selected during the prior installation. Install groups cannot be selected after the initial installation.
If InitConfig or Config artifacts are present for the smallest installable units (SIUs) federated by the newly selected features, see To configure the application in a non-repeatable manner.
To configure the application in a non-repeatable manner
The Initial Configure request is allowed at this state if InitConfig or Config artifacts are present in Sample App 1.0's IUDD. During the Create request, these artifacts place the software in the CREATED state, which is the only state where Initial Configure can be performed. To transition the software to the USABLE state, the Initial Configure request must be performed.
To apply a fix to an installed application
Fix IUDDs can be applied to existing software by performing the Update request. In this example, because Sample App 1.0 is installed, one or more fixes can be applied.
In the fix IUDD, Sample App Fix 1, all IUs from Sample App 1.0's IUDD are not required to be fixed. However, at a minimum, the RootIU and one other IU must be present in Sample App Fix 1.
To supersede an application with a newer version
Incremental update IUDDs can be applied to existing software by performing the Update request. In this example, because Sample App 1.0 is installed, an incremental update can be applied. In the incremental update IUDD, Sample App 1.1, all IUs from Sample App 1.0's IUDD are not required to be updated. However, at a minimum, the RootIU and one other IU must be present in Sample App 1.1.
After performing an incremental update, the software being updated will remain registered in Solution Install's installation database, but will be superseded by the incremental update.
New features cannot be introduced in incremental update IUDDs, but new IUs can be introduced. New IUs can either be selectable or non-selectable content. New selectable IUs must be federated by existing features. New non-selectable IUs are automatically installed during the Update request.
If Migrate or Config artifacts are present in the update IUDD, see To configure a recently applied update.
To upgrade an application to a newer version
Full update IUDDs can be applied to existing software by performing the Update request. Because Sample App 1.0 is installed, a full update can be applied. In the full update IUDD, Sample App 2.0, all IUs from Sample App 1.0's IUDD are required to be updated to the newer version.
New IUs and features can be introduced in full updates. New non-selectable IUs introduced in the full update IUDD are installed during the Update request. Similarly, new selectable IUs federated by previously selected features are also installed during the Update request.
However, to install newly introduced features from the full update IUDD, feature selection must be done during a Create request with the full update IUDD, after the Update request has been performed.
If Migrate or Config artifacts are present in the update IUDD, see To configure a recently applied update.
Individual unrequired features can be removed from the system by deselecting the desired features when performing a Delete request on the base version of the application (Sample App 1.0). This removes the deselected features and the IUs federated by them.
To uninstall an entire application
Sample App 1.0 can be uninstalled from the system by performing a Delete request.
Sample App Fix1 is applied to Sample App 1.0
At this point, let's go back to Sample App 1.0 has been installed on the system. The available fix, Sample App Fix1, has also been applied to Sample App 1.0.
Figure 2 indicates, by Yes or No, what possible change requests can be performed.
Figure 2. Sample App 1.0 and Sample App Fix 1
To install additional features
After Sample App Fix1 has been applied, you might need to install additional features that were not selected during the original installation. To do so, a Create request must be performed on Sample App 1.0 and you can select new features. Install groups cannot be selected after the initial installation.
Because Sample App Fix1 was applied before the additional features were installed, Sample App Fix1 must be reapplied for the newly installed features by performing the Update request. In the case where the newly
installed features federate an SIU that contains an InitConfigArtifact or a ConfigArtifact, the InitConfig request must be performed before reapplying the incremental update. In all other cases, no other Change requests can be performed on this application until the update is reapplied.
To configure newly installed features in a non-repeatable manner
If any of the newly installed features federate IUs that have InitConfig or Configure artifacts, these IUs
will be in CREATED state once they are installed. To transition the software to USABLE state,
the Initial Configure request must be performed.
To apply additional fixes to an installed application
Sample App Fix1 has already been applied to the installed application. There might be additional fixes available for Sample App 1.0, which may not supersede installed or available fixes.
In this example, Sample App Fix2 will be applied to Sample App 1.0 by performing the Update request. Sample App Fix2 does not supersede Sample App Fix1, so they share no relationship. See superseding fixes for more information.
Fixes can define prerequisites or exrequisites for other installed or available fixes. If Sample App Fix2 defined any prerequisite fixes, then those fixes must be applied prior to applying Sample App Fix2. If Sample App Fix2 defined any exrequisite fixes, Sample App Fix2 cannot be applied if those exrequisite fixes are installed. And, none of the exrequisite fixes can be applied if Sample App Fix2 is installed.
To supersede an application with a newer version
To supersede an installed application, an incremental update can be applied by performing the Update request. In this example, because Sample App 1.0 is installed, the incremental update Sample App 1.1 can be applied.
After performing an incremental update, the software being updated remains registered in Solution Install's installation database, but will be superseded by the incremental update. Although the incremental update, Sample App 1.1, implicitly supersedes previous versions of the application, any available fixes for the application Sample App 1.0 must be explicitly defined in the incremental update IUDD as superseded fixes.
If Migrate or Config artifacts are present in the update IUDD, see To configure a recently applied update.
To upgrade an application to a newer version
Full update IUDDs can be applied to existing software by performing the Update request. In this example, because Sample App 1.0 is installed, a full update (Sample App 2.0) can be applied.
Sample App 2.0 upgrades all previously installed versions of Sample App and any installed fixes for Sample App. Any available fixes for any previous version of Sample App must be explicitly defined in the full update IUDD as superseded fixes.
If Migrate or Config artifacts are present in the update IUDD, see To configure a recently applied update.
If Sample App Fix1 was applied in undoable mode, it can be undone by performing the Undo request. This only removes Sample App Fix1; Sample App 1.0 remains installed.
Individual unrequired features can be removed from the system by deselecting the desired features when performing a Delete request on the base version of the application, Sample App 1.0. This removes the deselected features and the IUs federated by them.
To uninstall an entire application
Sample App 1.0 can be uninstalled from the system by performing a Delete request, which uninstalls Sample App 1.0 and all associated fixes.
The Delete request can also be performed to remove individual unrequired features, and their associated fixes, that are installed.
Sample App 1.0 has been incrementally updated by Sample App 1.1
At this point, Sample App 1.0 has been superseded by Sample App 1.1, an incremental update.
Figure 3 indicates, by Yes or No, what possible change requests can be performed.
Figure 3. Sample App 1.0 and Sample App 1.1
To install additional features
After Sample App 1.1 has been applied, you might need to install additional features that were not selected during the original installation. To do so, a Create request must be performed on Sample App 1.0 and new feature selections can be made. Install groups cannot be selected after the initial installation.
Because Sample App 1.1 was applied before the additional features were installed, Sample App 1.1 must be
reapplied for the newly installed features by performing the Update request. In the case where the newly
installed feature federates an SIU that contains an InitConfigArtifact or a ConfigArtifact, the InitConfig request must be performed before reapplying the incremental update. In all other cases, no other Change requests can be performed on this application until the update is reapplied.
New features are not allowed in incremental update IUDDs. However, new selectable content is allowed but must be federated by existing features.
To configure newly installed features in a non-repeatable manner
If any of the newly installed features federate IUs that have InitConfig or Configure artifacts, these IUs are in the CREATED state after they are installed. To transition the software to USABLE state, the Initial Configure request must be performed.
To apply fixes to a superseding application
Sample App 1.1 is installed and implicitly supersedes Sample App 1.0. Therefore, no fixes can be applied to Sample App 1.0.
Fixes for Sample App 1.1, a superseding application, can be applied using the Update request. In this example, Sample App Fix is applied to Sample App 1.1.
No new features or IUs are permitted in a fix IUDD.
To supersede a superseding application with a newer version
To supersede an application, an incremental update can be applied by performing the Update request. Although the incremental update, Sample App 1.2, implicitly supersedes previous versions of the application, any available fixes for any version of our application Sample App must be explicitly defined in the incremental update IUDD as superseded fixes.
In this example, because Sample App 1.1 is installed, the incremental update Sample App 1.2 can be applied.
After performing an incremental update, the software being updated remains registered in Solution Install's installation database, but is superseded by the incremental update.
If Migrate or Config artifacts are present in the update IUDD, see To configure a recently applied update.
To upgrade an application to a newer version
Full update IUDDs can be applied to existing software by performing the Update request. In this example, because Sample App 1.0 and Sample App 1.1 are installed, a full update (Sample App 2.0) can be applied.
Sample App 2.0 upgrades all previously installed versions of Sample App and any installed fixes for Sample App.
If Migrate or Config artifacts are present in the update IUDD, see To configure a recently applied update.
To configure a recently applied update
The Migrate request is allowed at this state if Migrate or Config artifacts are present in the update IUDD. After the Update request, these artifacts place the
software in the UPDATED state, which is the only state where Migrate can be performed.
To transition the software to the USABLE state, the Migrate request must be performed.
To undo a superseding application
If Sample App 1.1 was applied in undoable mode, it can be undone by performing the Undo request. This only removes Sample App 1.1; Sample App 1.0 remains installed.
Individual unrequired features can be removed from the system by deselecting the features when performing a Delete request on the base version of the application (Sample App 1.0). This removes the deselected features and the IUs federated by them.
To uninstall an entire application
Sample App can be uninstalled from the system by performing a Delete request on Sample App 1.0, the base version of the application. This uninstalls Sample App 1.0 and Sample App 1.1.
A full update package, Sample App 2.0, is installed
There are two possible ways that Sample App 2.0 could be installed: by a Create request or by an Update request.
If no previous version of Sample App was installed on the system, the Create request would have been performed to install Sample App 2.0.
If a previous version of Sample App was installed, it would have been upgraded to Sample App 2.0 using the Update request. As a result, the previous version of Sample App, and its incremental updates and fixes, would be replaced by Sample App 2.0 in the installation database.
Regardless of which request was used to install Sample App 2.0, the possible Change requests at this stage are the same.
Figure 4 indicates, by Yes or No, what possible change requests can be performed.
Figure 4. Sample App 2.0
To install additional features
Full update IUDDs only replace features and IUs that were already installed. Features that were not installed prior to the update will not be installed at the time of the update. To install features that were not previously installed, the Create request must be performed after the Update request.
Full update IUDDs are also allowed to introduce new features that were not in the base IUDD. However, these features cannot be selected during the Update request. The Update request will only update existing features and IUs. To install the newly introduced features, feature selection must be done during a Create request with the full update IUDD. Install groups cannot be selected after the initial installation.
If InitConfig or Config artifacts are present for the SIUs federated by the newly selected features, see To configure IUs from a full update IUDD in a non-repeatable manner.
To configure IUs from a full update IUDD in a non-repeatable manner
There are three cases where you'll be able to perform an InitConfig request on a full update IUDD:
- When a full update package is installed as the initial application using the Create
request. Because there is no way of knowing whether the end user has a previous version installed when writing the IUDD,
InitConfigartifacts and anyMigrateartifacts should be included. If any of the IUs withInitConfigartifacts are installed, the Initial Configure request must be performed in order to transition the software to a USABLE state. - When the full update IUDD introduces new non-selectable IUs that contain
InitConfigorConfigartifacts. These new IUs are installed during the Update request and are in the CREATED state, so the InitialConfigure request must be performed before the Initial Configure request to transition the software to the USABLE state. - When additional features are installed after the Update request has already been performed,
and the IUs federated by these features have
InitConfigorConfigartifacts.
To apply fixes to an application
Fix IUDDs can be applied to existing software by performing the Update request. In this example, because Sample App 2.0 is installed, one or more fixes can be applied.
In the fix IUDD (Sample App Fix), all IUs from Sample App 2.0's IUDD are not required to be fixed. However, at a minimum, the RootIU and one other IU must be present in Sample App Fix.
No new features or IUs are permitted in a fix IUDD.
To supersede a superseding application with a newer version
Incremental update IUDDs can be applied to existing software by performing the Update request. In this example, because Sample App 2.0 is installed, an incremental update can be applied.
In the incremental update IUDD (Sample App 2.1), all IUs from Sample App 2.0's IUDD are not required to be updated. However, at a minimum, the RootIU and one other IU must be present in Sample App 2.1.
After performing an incremental update, the software being updated remains registered in Solution Install's installation database, but is superseded by the incremental update.
New features cannot be introduced in incremental update IUDDs, but new IUs can be introduced. New IUs can either be selectable or non-selectable content. New selectable IUs must be federated by existing features. New non-selectable IUs are automatically installed during the Update request.
If Migrate or Config artifacts are present in the update IUDD, see To configure a recently applied update.
request
To upgrade an application to a newer version
Full update IUDDs can be applied to existing software by performing the Update request. In this example, because Sample App 2.0 and Sample App 2.1 are installed, the full update Sample App 3.0 can be applied.
Sample App 3.0 upgrades all previously installed versions of Sample App and any installed fixes for Sample App.
If Migrate or Config artifacts are present in the update IUDD, see To configure a recently applied update.
To configure a recently applied update
The Migrate request is allowed at this state if the upgrade was applied using the Update request,
and Migrate or Config artifacts are present in Sample App 2.0's IUDD.
After the Update request, these artifacts place the software in an UPDATED state, which is the only state where Migrate can be performed.
To transition the software to the USABLE state, the Migrate request must be performed.
The Migrate request is not allowed if Sample App 2.0 was the first version installed, and was installed using the Create request.
As of Solution Install 1.2.1, undoing full updates is not supported.
Individual unrequired features can be removed from the system by deselecting the desired features when performing a Delete request on Sample App 2.0. This removes the deselected features and the IUs federated by them.
To uninstall an entire application
Sample App can be uninstalled from the system by performing a Delete request on Sample App 2.0. This uninstalls Sample App 2.0.
Sample App 1.0 has been fixed, then incrementally updated by Sample App 1.1
Now let's look at the situation where a fix, Sample App Fix1, has been applied to Sample App 1.0. Later an incremental update was applied to Sample App 1.0, and supersedes both Sample App 1.0 and Sample App Fix1.
Figure 5 indicates, by Yes or No, what possible change requests can be performed.
Figure 5. Sample App 1.0, Sample App Fix1, Sample App 1.1
To install additional features
After Sample App 1.1 has been applied, you might need to install additional features that were not selected during the original installation. To do so, a Create request must be performed on Sample App 1.0 and new feature selections can be made. Install groups cannot be selected after the initial installation.
Because Sample App 1.1 was applied before the additional features were installed, Sample App 1.1 must be
reapplied for the newly installed features by performing the Update request. In the case where the newly
installed feature federates an SIU that contains an InitConfig artifact or a Config artifact, the
InitConfig request must be performed before reapplying the incremental update.
In all other cases, no other Change requests can be performed on this application until the update is reapplied.
Because Sample App 1.1 supersedes Sample App Fix1, there is no need to reapply fixes for the newly installed features.
New features are not allowed in incremental update IUDDs. However, new selectable content is allowed, but must be federated by existing features.
To configure newly installed features in a non-repeatable manner
If any of the newly installed features federate IUs that have InitConfig or Configure artifacts, these IUs are in the CREATED state after they are installed. The InitialConfigure request must be performed in order to transition the software to the USABLE state.
To apply fixes to an application
Sample App 1.1 is installed, which implicitly supersedes Sample App 1.0 and explicitly supersedes its fixes. Therefore, no additional fixes can be applied to Sample App 1.0.
Fixes for Sample App 1.1, a superseding application, can be applied using the Update request. In this example, Sample App Fix2 is applied to Sample App 1.1.
No new features or IUs are permitted in a fix IUDD.
To supersede a superseding application with a newer version
To supersede an application, an incremental update can be applied by performing the Update request. Although the incremental update, Sample App 1.2, implicitly supersedes previous versions of the application, any available fixes for any version of the application Sample App must be explicitly defined in the incremental update IUDD as superseded fixes.
In this example, because Sample App 1.1 is installed, the incremental update Sample App 1.2 can be applied.
After performing an incremental update, the software being updated remains registered in Solution Install's installation database, but is superseded by the incremental update.
New features cannot be introduced in incremental update IUDDs, but new IUs can be introduced. New IUs can either be selectable or non-selectable content. New selectable IUs must be federated by existing features. New non-selectable IUs are automatically installed during the Update request.
If Migrate or Config artifacts are present in the update IUDD, see To configure a recently applied update.
To upgrade an application to a newer version
Full update IUDDs can be applied to existing software by performing the Update request. In this example, because Sample App 1.0 and Sample App 1.1 are installed, a full update Sample App 2.0 can be applied.
Sample App 2.0 upgrades all previously installed versions of Sample App, and any installed fixes for Sample App. Any available fixes for any previous version of Sample App must be explicitly defined in the full update IUDD as superseded fixes.
If Migrate or Config artifacts are present in the update IUDD, see To configure a recently applied update.
To configure a recently applied update
The Migrate request is allowed at this state if Migrate or Config artifacts are present in Sample App 1.1's IUDD. After the Update request, these artifacts place the software in the UPDATED state, which is the only state where Migrate can be performed. To transition the software to the USABLE state, the Migrate request must be performed.
If Sample App 1.1 was applied in undoable mode, it can be undone by performing the Undo request. This only removes Sample App 1.1; Sample App 1.0 and its fixes remain installed.
If you need to undo Sample App Fix1, then Sample App 1.1 must first be undone, given that both were applied in undoable mode. If Sample App 1.1 was not applied in undoable mode, Sample App Fix1 can never be undone.
In this example, only Sample App 1.1 is undone.
Individual unrequired features can be removed from the system by deselecting the desired features when performing a Delete request on the base version of Sample App 1.0. This removes the deselected features and the IUs federated by them.
To uninstall an entire application
Sample App can be uninstalled from the system by performing a Delete request on the base version of the application Sample App 1.0. This uninstalls Sample App 1.0, Sample App 1.1, and all fixes associated with Sample App.
Sample App 1.0 has been fixed, incrementally updated, then fixed again by a superseding fix
A fix, Sample App Fix1, has been applied to Sample App 1.0. Later an incremental update, Sample App 1.1, was applied to Sample App 1.0, and supersedes both Sample App 1.0 and Sample App Fix1. Then Sample App Fix2, a second fix, is applied that explicitly supersedes Sample App Fix1. Sample App Fix2's required base must include Sample App 1.1.
Sample App Fix2 can supersede Sample App Fix1, even if Sample App Fix1 is not installed. In that case, Sample App Fix1 cannot be applied after Sample App Fix2 has been applied.
Figure 6 indicates, by Yes or No, what possible change requests can be performed.
Figure 6. Sample App 1.0, Sample App Fix1, Sample App 1.1, Sample App Fix2
To install additional features
After Sample App 1.1 has been applied, you might need to install additional features that were not selected during the original installation. To do so, a Create request must be performed on Sample App 1.0 and new feature selections can be made. Install groups cannot be selected after the initial installation.
Because Sample App 1.1 was applied before the additional features were installed, Sample App 1.1 must be
reapplied for the newly installed features by performing the Update request. In the case where the newly
installed feature federates an SIU that contains an InitConfig artifact or a Config artifact, the
InitConfig request must be performed before reapplying the incremental update.
In all other cases, no other Change requests can be performed on this application until the update is reapplied.
Because Sample App 1.1 supersedes Sample App Fix1, there is no need to reapply Sample App Fix1 for the newly installed features. However, Sample App 1.1 and Sample App Fix2 should be reapplied to the newly installed features, respectively.
To configure newly installed features in a non-repeatable manner
If any of the newly installed features federate IUs that have InitConfig or Configure artifacts, these IUs
will be in the CREATED state after they are installed. To transition the software to the USABLE state,
the InitialConfigure request must be performed.
To apply fixes to an application
Sample App 1.1 is installed, which implicitly supersedes Sample App 1.0 and explicitly supersedes its fixes. Therefore, no additional fixes can be applied to Sample App 1.0.
Additional fixes for Sample App 1.1, a superseding application, can be applied using the Update request. In this example, Sample App Fix3 is applied to Sample App 1.1, and may or may not supersede Sample App Fix2.
No new features or IUs are permitted in a fix IUDD.
To supersede a superseding application with a newer version
To supersede an application, an incremental update can be applied by performing the Update request. Although the incremental update, Sample App 1.2, implicitly supersedes previous versions of the application, any fixes available for Sample App 1.1 must be explicitly defined in the incremental update deployment IUDD as superseded fixes. So, in this example, Sample App 1.2 must declare Sample App Fix2 as a superseded fix.
Because Sample App 1.1 is installed, the incremental update Sample App 1.2 can be applied.
After performing an incremental update, the software being updated remains registered in Solution Install''s installation database, but is superseded by the incremental update.
New features cannot be introduced in incremental update IUDDs, but new IUs can be introduced. New IUs can either be selectable or non-selectable content. New selectable IUs must be federated by existing features. New non-selectable IUs will be automatically installed during the Update request.
If Migrate or Config artifacts are present in the update IUDD, see To configure a recently applied update.
To upgrade an application to a newer version
Full update IUDDs can be applied to existing software by performing the Update request. In this example, because Sample App 1.0 and Sample App 1.1 are installed, a full update Sample App 2.0 can be applied.
Sample App 2.0 upgrades all previously installed versions of Sample App and any installed fixes for Sample App. Any available fixes for any previous version of Sample App must be explicitly defined in the full update IUDD as superseded fixes.
If Migrate or Config artifacts are present in the update IUDD, see To configure a recently applied update.
If Sample App Fix2 was applied in undoable mode, it can be undone by performing the Undo request. This only removes Sample App Fix2.
The Undo request cannot be performed on superseded instances. To undo a superseded instance, all superseding instances must be undone first. Likewise, incremental update instances cannot be undone if fixes are applied to them. These fixes must be undone before the incremental update can be undone.
In this example, the undo order is: Sample App Fix2, Sample App 1.1, then Sample App Fix1, given that all three were applied in undoable mode.
Individual unrequired features can be removed from the system by deselecting the desired features when performing a Delete request on the base version of the application (Sample App 1.0). This removes the deselected features and the IUs federated by them.
To uninstall an entire application
Sample App can be uninstalled from the system by performing a Delete request on the base version of the application (Sample App 1.0). This uninstalls Sample App 1.0, Sample App 1.1, and all fixes associated with Sample App.
Sample App 1.0 has been fixed, then fixed again with a non-superseding fix
A fix, Sample App Fix1, has been applied to Sample App 1.0. Then Sample App Fix2, a second fix, is applied that does not supersede Sample App Fix1.
Figure 7 indicates, by Yes or No, what possible change requests can be performed.
Figure 7. Sample App 1.0, Sample App Fix1, Sample App Fix2
To install additional features
After Sample App 1.1 has been applied, you might need to install additional features that were not selected during the original installation. To do so, a Create request must be performed on Sample App 1.0 and new feature selections can be made. Install groups cannot be selected after the initial installation.
Because Sample App Fix1 and Sample App Fix2 were applied before the additional features were installed, these two fixes must be reapplied for the newly installed features by performing the Update request. Because Sample App Fix2 does not supersede Sample App Fix1, the fixes can be reapplied in any order.
In the case where the newly installed feature federates an SIU that contains an InitConfig artifact or a Config artifact, the InitConfig request must be performed before reapplying the fixes. In all other cases, no other Change requests can be performed on this application until the fixes are reapplied.
To configure newly installed features in a non-repeatable manner
If any of the newly installed features federate IUs that have InitConfig or Configure artifacts, these IUs are in the CREATED state after they are installed. To transition the software to the USABLE state, the Initial Configure request must be performed.
To apply fixes to an application
Additional fixes for Sample App 1.0 can be applied using the Update request. In this example, Sample App Fix3 is applied to Sample App 1.0, and may or may not supersede Sample App Fix1 or Sample App Fix2.
No new features or IUs are permitted in a fix IUDD.
To supersede a superseding application with a newer version
To supersede an application, you can apply an incremental update by performing the Update request. Although the incremental update, Sample App 1.1, implicitly supersedes previous versions of the application, any fixes available for Sample App 1.0 must be explicitly defined in the incremental update IUDD as superseded fixes. So, in this example, Sample App 1.1 must declare Sample App Fix1 and Sample App Fix2 as superseded fixes.
After performing an incremental update, the software being updated remain registereds in Solution Install's installation database, but is superseded by the incremental update.
New features cannot be introduced in incremental update IUDDs, but new IUs can be introduced. New IUs can either be selectable or non-selectable content. New selectable IUs must be federated by existing features. New non-selectable IUs will be automatically installed during the Update request.
If Migrate or Config artifacts are present in the update IUDD, see To configure a recently applied update.
To upgrade an application to a newer version
Full update IUDDs can be applied to existing software by performing the Update request. In this example, because Sample App 1.0 is installed, a full update Sample App 2.0 can be applied.
Sample App 2.0 upgrades all previously installed versions of Sample App and any installed fixes for Sample App. Any available fixes for any previous version of Sample App must be explicitly defined in the full update IUDD as superseded fixes.
If Migrate or Config artifacts are present in the update IUDD, see To configure a recently applied update.
If Sample App Fix2 was applied in undoable mode, it can be undone by performing the Undo request. This only removes Sample App Fix2.
Because neither of the two fixes is superseded, they can be undone in any order because they were applied in undoable mode.
Individual unrequired features can be removed from the system by deselecting the desired features when performing a Delete request on the base version of the application (Sample App 1.0). This removes the deselected features and the IUs federated by them.
To uninstall an entire application
Sample App can be uninstalled from the system by performing a Delete request on the base version of the application (Sample App 1.0). This uninstalls Sample App 1.0 and all fixes associated with Sample App.
Sample App's package contains a Configuration Unit Deployment Descriptor (CUDD)
If a CUDD, a package containing a RootCU as opposed to a RootIU, is available in Sample App's package, the Configure request can be performed. These actions are repeatable, and the CUDD can be processed as many times as needed.
The results of this Change request are not persisted by Solution Install, meaning that nothing is registered in the database as a result of the Change request.
As this article demonstrates, different change requests are suitable to take an application from one stage to another. Not all change requests are applicable for every stage. Depending on the application's current and desired stage, there may be some caveats or things users should pay closer attention to. We hope this article helps those who are leveraging the Solution Install technology to create a software package and installation program that meets the Solution Install requirements to take the application to your desired stage.
Learn
-
"Simplify deployment tasks with Solution Installation technology: A close encounter with Solution Installation descriptors" (developerWorks, 2005): Read more information on the Solution Installation IUDD.
Get products and technologies
-
To learn more about Solution Install and to download the Autonomic Computing Toolkit, visit the
Autonomic Toolkit overview Web site.
Discuss
-
View Dave Bartlett's blog on autonomic computing to read his thoughts.
-
An insider's perspective. Get involved in the autonomic computing discussion.
Angela R Jones (Angie) has worked on Solution Installation for Autonomic Computing since its very first release in 2003. As a result, she is very familiar with the design and implementation of Solution Installation. Angie has a degree in Computer Science from Tennessee State University and currently works at IBM in Research Triangle Park, NC. Angie can be reached at rangela@us.ibm.com.
Kaushik Patel has worked in the Solution Installation for Autonomic Computing group since March 2004, focusing mainly on verification aspects. By working very closely with exploiters who are leveraging the Solution Installation technology, he has a good understanding of how exploiters use this component as well as areas where exploiters can use some additional help. Kaushik has a degree in Electrical Engineering from the New Jersey Institute of Technology and has worked for IBM for 9 years. He can be reached at patelka@us.ibm.com.
Table of contents
- Introduction
- When an application is not installed
- Sample App 1.0 is installed
- Sample App Fix1 is applied
- Sample App 1.0 has been incrementally updated
- A full update package is installed
- Sample App 1.0 has been fixed, then incrementally updated
- Sample App 1.0 has been fixed, incrementally updated, and fixed again
- Sample App 1.0 has been fixed, then fixed again with a non-superseding fix
- Sample App's package contains a Configuration Unit Deployment Descriptor (CUDD)
- Summary
- Resources
- About the authors
- Comments
