Operations Issues

[Julia McCarthy <julia@us.ibm.com>]

Hi all,

We agreed in our meeting this morning to try to make more progress on this issue via email. Brent took good notes on our discussion, so if you want to refresh your memory read today's minutes before diving into this note. I'm going to kick off the discussion by providing an example that demonstrates one complexity of supporting all combinations of operations in the same SDD.

Example: An illustration of the awkwardness of supporting install, update and configuration of selectable content in the same package.

Imagine an SDD for Product X with a Feature A. Feature A selects a content element that deploys Resource A. Installing the SDD and selecting feature A results in the installation of Resource A. (So far, its simple.) Now imagine an SDD that updates Product X. The content element that updates Resource A belongs in base content with a condition on the presence of Resource A.

(If this surprises you, it is because we have not yet talked through feature semantics. Features have no lifecycle. They do not correspond with anything in the deployment environment. They are statements of allowed selectability within one package only. They do not imply correspondence to features in previous packaging of the software. In our example, the update for Product X does not allow you to select Feature A while doing the update. It is designed to update Resource A if it is there.)

So, for Product X, the InstallableUnit that creates Resource A belongs in the SelectableContent hierarchy while the InstallableUnit that updates Resource A belongs in the BaseContent hierarchy. If we allow install and update to be supported in the same SDD, then the install would have be in a different InstallableUnit than the update.

If Product X included a ConfigurationUnit that configured Resource A when Feature A is selected, and it also supported the configuration operation run separately from the install, then the situation is similar. The post-install configuration of selectable content, like an update of selectable content, goes in the BaseContent hierarchy with a condition on the selectable content. Since, in our example, the same configuration is required both during install and post-install, there would have to be one ConfigurationUnit in selectable content to configure Resource A and one ConfigurationUnit in BaseContent to support post-install configuration of Product X even though both ConfigurationUnits do the exact same thing. (They could point to the same artifact, but other elements like the ResultingChange, would be duplicated.)


This example tends to make me want to say let's just not support install and update or install and configure in the same package, although I can't say anything is broken. Thoughts everyone?


Julia McCarthy
Install Strategy and Development
julia@us.ibm.com
349/8156
877-261-0391