[OASIS Issue Tracker] (CAMP-184) Entity Immutability

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

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

David Laurance commented on CAMP-184:
-------------------------------------

In issue 183, I added the following scenario:
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.

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.

The discussion in 183 is about what PlanVersion Gil wants to use when deploying Assembly S.1.
This issue seems to concern the question of what happens over time to PlanVersion P.x.  I think this issue might resolve to say that PlanVersions are immutable once they're in the Plan Repository, and all changes to Plans are made by creating new PlanVersions.

I could show this with a modification of the scenario from Issue 183:
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.  I will extend the scenario, and make an assumption 

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.
 
Assembly S.1 may use PlanVersion P.1 or P.2, depending on the resolution of 183.  Let's agree that it uses P.x, where x is either 1 or 2.
I believe that P.x must be immutable.  In other words, if we continue the scenario:

> Thursday: David revises Plan P once more, to create PlanVersion P.3.
> Friday: Assembly S.1 is still deployed, and some operator or operational process has a need to interrogate it.  
   Assembly S.1 must continue to refer to PlanVersion P.x, and P.x must not have changed since Wednesday.

Note that the simplest implementation would be for PlanVersion P.x to have been immutable since its creation, on Monday (for P.2) or earlier (for P.1).  But the requirement is that it must be immutable only since Assembly S.1 started, and it was first used.



> Entity Immutability
> -------------------
>
>                 Key: CAMP-184
>                 URL: https://issues.oasis-open.org/browse/CAMP-184
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Improvement
>          Components: Spec
>    Affects Versions: 1.2
>            Reporter: Michael Norman
>            Assignee: Gilbert Pilz
>            Priority: Minor
>
> For audit purposes we would like to ensure the Plan from which an Assembly is initiated is immutable.  In general it may be best to ensure that all entities within the domain model are "copy-on-write", and we can have a generic way of accessing versions of entities through the API.



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