[OASIS Issue Tracker] (CAMP-183) Decouple the Plan Repository from the Platform

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/CAMP-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60378#comment-60378 ] 

David Laurance commented on CAMP-183:
-------------------------------------

Mike has a good articulation of the separation in UML diagrams.  The key concept is that Plan and Artifact have versions, and an Assembly is built from specific versions of Plans and Artifacts.

When you instantiate an Assembly , you take a version of a Plan - a PlanVersion.  The PlanVersion must remain immutable, so that during the lifetime of your Assembly you can trace back to the PlanVersion as needed.  Likewise, you take versions of any Artifacts used by the Plan, and specifications for those ArtifactVersions are immutable for the same reason.

Here is a scenario for discussion:
Initial state:
>  Plan P.1 is defined, and uses Artifact A.1.
Events:
> Monday:  David revises Plan P, to create PlanVersion P.2.
> Tuesday: Mike revises Artifact A to create ArtifactVersion A.2.
> Wednesday: Gil  deploys Assembly S.1 using Plan P.

It seems clear enough that Gil's deployment should use PlanVersion P.2 in the normal use case.

What ArtifactVersion should Gil's deployment use?

I think there are three possible answers.
A.  Gil could expect to deploy from the most recent versions of Plans and Artifacts; in that case, Assembly S.1 would include PlanVersion P.2 and ArtifactVersion A.2.  
B. Gil could expect to deply exactly what David saw when he specified the most recent Plan; in that case, Assembly S.1 would include PlanVersion P.2 and ArtifactVersion A.1.  
C. Gil could expect to make explicit choices at time of deployment, in which case he could chose either A.1 or A.2.

For any of the choices, it seems clear that we need to posit a Manifest that lists PlanVersion and ArtifactVersions.  If choice A above is always correct, then that Manifest is associated with PlanVersion P.2, and used by Assembly S.1.  If choices B or C are appropriate, then the Manifest is associated with Assembly S.1, since other Assemblies built on Plan P.1 may have different ArtifactVersions from S.1.



> Decouple the Plan Repository from the Platform
> ----------------------------------------------
>
>                 Key: CAMP-183
>                 URL: https://issues.oasis-open.org/browse/CAMP-183
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Improvement
>          Components: Spec
>    Affects Versions: 1.2
>            Reporter: Mike Norman
>            Assignee: Mike Norman
>            Priority: Critical
>
> At the moment a Platform has many Plans, and a Plan belongs to a Platform.  We would like to decouple the notion of a Plan Repository from a Platform. So a top-level entity (which we refer to as an Enterprise) would have zero or many Platforms, and also have zero or many Plan Repositories.  A Plan Repository would have zero or many Plans (and so on through the child entities of a Plan).  An Assembly would instantiate a Plan (loosely, a Plan would have zero or more Assemblies in zero or more Platforms).  Then everything is back to the existing domain model.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)