OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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

Michael Norman commented on CAMP-183:
-------------------------------------

We fundamentally don't see this the same way.  Thing 1 and Thing 2 are of the same entity type (i.e. Plan). One may be created by enriching the other, but they are definitely the same entity type. A different entity type is created at instantiation (i.e. the Assembly). The yml/json thing is a detail of how the Plan is serialized. And the detail of how a Platform is going to resolve a requirement is made instantaneously (because the set of available services is dynamic) so this idea of caching partial resolutions simply doesn't work, unless you are prepared to continuously manage them.  Plus the requirements aren't necessarily resolved by Services on the same Platform as the one on which the Assembly itself is running. 

So in short the thing 1 thing 2 approach is just adding more confusion. The bottom line is that the Plans are non-instantiated entities and live in repositories and they are versioned.  There may be a local copy of the Plan inside the Platform which has been enriched in some way by the Platform, but there doesn't have to be.  there can just be a reference back to the Plan in the Repository.  This in turn will have reference to the artifacts (which will also be in a repository, although not necessarily the same one). 

However, in the absence of a resolution to this  We can clearly add the Plan Repository as an extension. If we then make the Platform on a Plan optional, then strictly-speaking we are in compliance with the API even if the  API isn't directly carrying the semantics we need.


> 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: Michael Norman
>            Assignee: Michael Norman
>            Priority: Trivial
>             Fix For: 1.2
>
>
> 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)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]