1 / 12

CL1 Proposal

CL1 Proposal. Redefine “install”. Add update artifact. Remove inconsistencies introduced by “baseUninstall” package type. Operation – Artifact Mapping. Current

nasim-alvarez
Download Presentation

CL1 Proposal

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CL1 Proposal Redefine “install”. Add update artifact. Remove inconsistencies introduced by “baseUninstall” package type.

  2. Operation – Artifact Mapping • Current • Operations are used in requirements to indicate how the requirement applies to artifacts. (Or in the case of “use” to indicate that the requirement does not apply to the artifacts only to use of the deployed software.) • Operations are used in completion elements to indicate how completion actions are associated with artifacts. • Operation values include “granular” operations and “macro” operations. “Macro” operations are used as a convenience to refer to multiple operations. The two macro operations are Install and InstallAndUse. • The install artifact can map to either create or update or both. All the other artifacts map to a single operation. The installType attribute of a content element is used to indicate if the InstallArtifact can be used with create, update or both. • Issue • A package type of “baseUninstall” is inconsistent with the expression of the required installType attribute and inconsistent with requirement of the InstallArtifact element. • Packages intended to provide only repair, verification or undo have no corresponding package type and are inconsistent with requirement of the InstallArtifact element. • It is not possible to support both install and update in one package if they use different artifact files. • Proposal • Redefine “install” to replace “create” instead of referring to either “create” or “update”. This parallels our recent redefinition of “uninstall” to replace “delete” instead of referring to “delete” or “undo”. Remove “create”. • Add an UpdateArtifact element to InstallableArtifactsType. Leave the InstallArtifact - with its new purpose. • This allows install and update to use either the same or different artifacts as required. • This makes all mapping of operations to artifacts one-to-one. • Remove the installType attribute from InstallUnitType. • Not needed because now the presence of the artifact element indicates support for the corresponding operation. • Installable units will no long claim to support install or update in a package that is identified as an uninstall package. • Make the install and update artifacts optional. • An uninstall package would presumably only include uninstall artifacts. • Add a new “macro” operation “updateAndUse” to support expression of requirements and completion actions that apply to both update processing and use of the deployed updates. • If there are requirements that apply to any other combination of operations, the requirement can be defined multiple times – once for each applicable operation. • Make operation required. Remove the default. • Add new package types: verification, repair and undo.

  3. Proposed CL1 Schema Change - artifacts • <complexType name="InstallableArtifactsType"> • <sequence> • <element name="InstallArtifact" type="sdd-dd:ArtifactType"/> • <element name="UndoArtifact" type="sdd-dd:ArtifactType" minOccurs="0"/> • <element name="UninstallArtifact" type="sdd-dd:ArtifactType" minOccurs="0"/> • <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> • </sequence> • </complexType> • <complexType name="InstallableArtifactsType"> • <sequence> • <element name=“InstallArtifact" type="sdd-dd:ArtifactType"/> • <element name="UpdateArtifact" type="sdd-dd:ArtifactType"/> • <element name="UndoArtifact" type="sdd-dd:ArtifactType" minOccurs="0"/> • <element name="UninstallArtifact" type="sdd-dd:ArtifactType" minOccurs="0"/> • <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> • </sequence> • </complexType> This change affects the list of artifact elements in InstallableUnits and LocalizationUnits.

  4. Proposed Schema Change – remove installType • <complexType name="InstallUnitType"> • <complexContent> • <extension base="sdd-dd:BaseUnitType"> • <sequence> • <element name="SupportedLanguages" type="sdd-dd:LanguageSetType" minOccurs="0"/> • <element name="RequiredBase" type="sdd-dd:RequiredBaseType" minOccurs="0"/> • <element name="Requirements" type="sdd-dd:RequirementsType" minOccurs="0"/> • </sequence> • <attribute name="installType" type="sdd-dd:InstallTypeType" use="optional" default="baseInstall"/> • <anyAttribute namespace="##other" processContents="lax"/> • </extension> • </complexContent> • </complexType> This change affects InstallableUnits, LocalizationUnits and, in CL2, CompositeInstallable.

  5. Proposed Schema Change – new package types <simpleType name="SDDPackageTypeType"> <restriction base="NCName"> <enumeration value="baseInstall"/> <enumeration value="baseUninstall"/> <enumeration value="configuration"/> <enumeration value="maintenance"/> <enumeration value="modification"/> <enumeration value="replacement"/> <enumeration value=“repair"/> <enumeration value=“verification"/> <enumeration value=“undo"/> </restriction> </simpleType>

  6. Proposed Schema Change – operation enum • <simpleType name="OperationApplicabilityType"> • <restriction base="NCName"> • <enumeration value="configure"/> • <enumeration value="create"/> • <enumeration value="install"/> • <enumeration value="installAndUse"/> **default • <enumeration value="repair"/> • <enumeration value="undo"/> • <enumeration value="update"/> • <enumeration value=“updateAndUse"/> <enumeration value="use"/> • <enumeration value="uninstall"/> • <enumeration value="verifyConfiguration"/> • <enumeration value="verifyResults"/> • </restriction> • </simpleType>

  7. Proposed Specification Changes • Many minor changes to references to InstallArtifact. This will simplify a number of sentences. • Example: Old: “A resource that will be updated when the InstallableUnit’s InstallArtifact is processed for an update operation.” New: “A resource that will be updated when the InstallableUnit’s UpdateArtifact is processed.” • Remove: • installType: The installType attribute communicates whether the create and update operations are supported by the defining InstallableUnit or LocalizationUnit. Valid values for installType are: • baseInstall: This value for installType indicates that the InstallArtifact can be used only to create new resources. • updateOnly: This value indicates that the InstallArtifact can be used only to update existing resources. • updateOrBaseInstall: This value indicates that the InstallArtifact can be used either to create new resources or to update existing resources. If no installType is specified, the type defaults to “baseInstall”. • Redefine InstallArtifact element and add UpdateArtifact: • InstallArtifact: The InstallArtifact element declares deployment information sufficient to enable the target resource to perform a create or update using the named artifact files. See ArtifactType for structure and usage details [6.3.3]. • InstallArtifact: The InstallArtifact element declares deployment information sufficient to enable the target resource to perform an install operation It is optional. See ArtifactType for structure and usage details [6.3.3]. • UpdateArtifact: The UpdateArtifact element declares deployment information sufficient to enable the target resource to perform an update operation. It is optional. See ArtifactType for structure and usage details [6.3.3]. • Update PackageType and OperationApplicabilityType enumerations. • Plus picture and table changes as needed.

  8. An inconsistency that remains: InstallableUnits that do not install • When we added a package type of “baseUninstall” we opened a can of worms. Previously an underlying assumption of the SDD was that it existed to support deployment of resources, either by creation or update. InstallArtifact was required. Other artifacts were included to support additional, future, lifecycle operations. • Changes proposed here to provide consistency with the newly added “baseUninstall” create a new inconsistency. Specifically, we now have a thing called “InstallableUnit” that might only have uninstall artifacts; or only repair artifacts; or only verification artifacts; or only undo artifacts. • Three options: • Let the naming inconsistency be OK. • Remove the inconsistency introduced by “baseUninstall” by deciding to keep to the original assumption that SDDs always describe deployment. • Remove “baseUninstall” package type; • do not accept the newly proposed package types; • and let the specification state that an InstallableUnit must have at least one of InstallArtifact or UpdateArtifact. • Change the name of “InstallableUnit” to ??? … something else.

  9. Backup Slides that further explain and illustrate the current situation and issues identified on slide 2.

  10. Current Situation Operation defaults to the macro operation “install”, which covers create and update. Here’s a requirement from SimpleApp that takes the default. This requirement must be met when the InstallArtifact is processed. If you add the text in teal, this becomes a requirement for processing the UninstallArtifact. <sdd-dd:Requirement id="OS.reqt“ operation=“uninstall”> <sdd-dd:Description> Simple Application Client is supported on AIX V5.3 and Windows XP Professional</sdd-dd:Description> … </sdd-dd:Requirement> A single content element may contain requirements for multiple operations – but only for operations associated with artifact elements that it defines.

  11. Issue: “BaseUninstall” introduces inconsistency • We recently added the package type “baseUninstall” which indicates that the package is intended to be used to uninstall resources. <sdd-pd:PackageIdentity softwareID="3000-123" packageType="baseUnInstall"> • The UninstallArtifacts in the deployment descriptor will be in InstallableUnits (or LocalizationUnits). <sdd-dd:InstallableUnit id="App01" targetResourceRef="os" installType="baseInstall"> … <sdd-dd:Artifacts> <sdd-dd:InstallArtifact /> <sdd-dd:UninstallArtifact type="jar" fileRef="SAC_UninstallArtifact"> <sdd-dd:Arguments> <sdd-dd:Argument name="$(InstallLocation)" /> </sdd-dd:Arguments> </sdd-dd:UninstallArtifact> </sdd-dd:Artifacts> </sdd-dd:InstallableUnit> Notice that the InstallableUnit has an installType and an InstallArtifact, both of which are required and neither of which make sense in an uninstall package. Notice that a fundamental assumption of the SDD is that an SDD always creates or updates.

  12. Issue: Create and Update must share artifact files • The current InstallArtifact definition works well in SDDs that support both create and update only when a single artifact file supports both create and update. (ArtifactType can define only one artifactFile plus one set of AdditionalFiles.) • Anyone who wants to package an SDD that uses different artifact files to support create and update would be forced to create two different InstallableUnits and set “installType” to baseInstall on one and to “updateOnly” on the other. This requires aggregation (CL2) and the ability to define a condition on operation (not CL1 or CL2). • How could you know when a create of the overall SDD required only a create or only an update of the split InstallableUnit? This situation adds even more complexity to our CL2 “Cascading Operations” issue.

More Related