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=59329#comment-59329 ] 

Alex Heneveld commented on CAMP-183:

I see a few options:

(1) there is *no* plan repo in CAMP; i deploy assemblies and they refer to URL's (external) where plans live

(2) there is *exactly one* plan repo exposed in a CAMP server; this is the current

(3) there are *many* plan repos exposed in one CAMP server; this is Mike's suggestion

If we do (1) we lose the ability to track blueprints which are deployed, and we lose the ability to define short-name URI's (e.g. "bash-server" as synonym for longer URI).  (Any other reasons we have a plans endpoint?)  If these capabilities cause a lot of complexity however, it might be better to take this option.

With the current spec (2) there is nothing to stop an implementation having multiple underlying repositories, but it sort of assumes a canonical list is kept at the CAMP server -- or at least a canonical resolution strategy for a plan reference which is not too inefficient.

Option (3) facilitates lots of external repositories, making those repositories explicit to an end user.  I tend to think there is NOT benefit in this.  why should the underlying repository structure be exposed to the end user?  it would only be to add a huge new repo.  but i could equally (and currently in brooklyn) add plans which point at external plans.  this keeps the search localised and the API simpler.

> 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
>            Reporter: Mike Norman
> 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

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