Fw: Rollback - Reqt 2.1.1.6.1

[Christine Draper <cdraper@us.ibm.com>]

All,

I was asked to put together a description of how the information in the current SDD schema could be used during rollback, as part of considering whether any further action is needed to address requirement 2.1.1.6.1:

The SDD specification must support the identification of components that should be rolled back if later components fail, and identification of components that should cause an overall rollback if that component fails to install.

Here's the analysis.

SUMMARY

The current schema can support:

1. Full rollback of a new solution or update to a solution, providing the appropriate artifacts are provided.
2. Partial rollback of a new solution to reestablish a valid system configuration, backing out optional components that had failed to install or caused functional problems.
3. Partial rollback of an update to a solution to reestablish a valid system configuration, where updates are provided as requisites and the previous version already met the solution requirements.
4. Fine-grained rollback of part of a solution update, before retrying the same update.

The schema elements that support this are:

• Selectable content, which indicates optional components of an IU package that may be selected for rollback.
• Requisites, which distinguish components of the solution, from separately installable IUs which need not be rolled-back.
• Internal dependencies, which can be used to identify IUs that must be rolled-back as well as the selected IU.
• Requirements/resulting resources, which can be used to identify when an IU from one package is required by an IU from another package (and so must be rolled-back as well).
• Uninstall element for new SIUs; Undo element for update SIUs; UndoConfig element for SCUs which provide the content needed for rollback.
• Internal & external dependencies for a given lifecycle operation, which can be used to modify the order in which rollback occurs.

There are details to be worked on what the SDD spec should say about rollback order, see discussion below.

There are details to be worked about the connection between features and selectable content, and what this should mean for rollback granularity.

Support for partial rollback of a maintenance update to a solution (3) may require further discussion.  


GORY DETAILS

Rollback of an SIU/SCU

The basic behavior for rollback of an SIU/SCU is:

• For a new install SIU, to rollback after either the install or install-config operations, perform uninstall operation on the SIU. If there is no uninstall element, then it is assumed that appropriate cleanup is performed by the uninstall of other SIUs in the package. If so, the package must ensure the uninstall is correctly sequenced, see note later. Of course, a may omit the uninstall element and perform no cleanup on uninstall - this would usually be considered badly-behaved, but there may be some circumstances in which this is the only option.
• For an update SIU, to rollback after either the install or install-config operations, perform undo operation on the SIU. If undo is not supported (no undo element), then this SIU cannot be rolled-back.
• For an SCU, to rollback after the install-config operation (in an IU package) or the config operation (in a CU package), perform undoConfig operation. If undoConfig is not supported, then this SCU cannot be rolled-back.

If an error occurs whilst an SIU/SCU operation is in-flight, then one of three situations may occur:

• Target environment is able to rollback the in-flight operation (guaranteed atomic transaction).
• Target environment is not able to rollback the in-flight operation, but the "undo" operation is robust when being applied to a partially-done operation.
• Target environment is not able to rollback the in-flight operation, "undo" operation is not robust or doesn't exist. In this case, cleanup may not be complete. I don't think the runtime/SDD can do anything more about this (other than warn the user).

Order of Rollback

Typically, a runtime is likely to reverse the order of install in order to rollback. There are a couple of complications:

• The split into install and install-config operations. These are undone by a single operation for an SIU.
• The case where uninstall order needs to be different from install order. This will be indicated using internal dependencies (specifying that it is an uninstall dependency).

We need to decide what the spec should say about rollback order. Here is one possibility. 
For each composite IU:

• Undo any child CUs in reverse order of install-config.
• Then undo any child update IUs in reverse order of install.
• Then uninstall any child new IUs based on explicit dependencies.

Alternatively, we could assert that undo order has to be explicitly defined using internal dependencies. 


Rollback Extent

The simplest assumption is full rollback - i.e. that all operations performed in a given "transaction" are to be rolled-back. 

There are two purposes for a finer-grained rollback may have one of two purposes:

• Reestablish a valid system configuration, backing out updates that had failed or caused functional problems.
• Cleanup before retrying the same system update. This could be much finer-grained. Any set of IUs might be rolled-back, providing they are then reinstalled according to the constraints on install order (and aren't installed twice without an undo in between).

The various possibilities for partial rollback will likely be driven by user or policy decisions. With the current schema, an SDD author cannot constrain partial rollback providing it re-establishes a valid system configuration.

Possible granularities of partial rollback to reestablish a valid system configuration are:

1. Rollback the top-level IU package and all its composed components. Do not rollback its requisites.
2. Rollback a new optional component of the top-level IU package, and anything that depends on it.
3. Rollback a new optional component of a composed IU package, and anything that depends on it.
4. Rollback an update in a contained IU package which updates a shared (federated) resource, providing the pre-existing version satisfied the solution requirements. This is problematic, see below.
5. Rollback an update in a requisite IU package which updates a shared resource, providing the pre-existing version satisfied the solution requirements (user had chosen to apply the more recent level, even though the original level was within range).

I haven't defined "optional component" in (2) and (3). This could either be:

• A single selectable content IU/CU (elements immediately under selectableContent in an IU package).
• The set of selectable content IU/CUs that correspond to removing a feature (and not used in another feature)

This point should be resolved when we close on the semantics of features - e.g. are features to assist a user in making good selections, or a mandatory contract defining what can be selected.

For (4), we would need to agree under what circumstances it is valid to rollback an update to one component of a solution, but not the overall solution. The current assumption is that the solution requires the composed level, or a more recent, backwards-compatible level. If the update is actually "optional", it could be better shipped as a requisite (although not all runtimes would support choosing to install a more recent requisite if the base requirement was satisfied).  So I would argue that updates to contained components cannot be individually rolledback.

Note on Schema Element Names

Note: Schema currently has element names of  "xxxArtifact" for each operation. I think it would be more accurate if we changed this to just "xxx" (e.g. install, undo), as there does not have to be an actual artifact for each operation.

Regards,
Christine


Senior Technical Staff Member
IBM, 11501 Burnet Road, Mail Point 901-6B10
Austin, TX 78758
1-512-838-3482 tl 678-3482