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

Gilbert Pilz commented on CAMP-183:
-----------------------------------

From my point of view, Thing 2 is more than just a "cached" copy of Thing 1. Thing 2 is the result of a process of matching the requirements in Thing 1 against the capabilities of the Platform. If you inspect the artifact:requirements:fulfillment:href's in Thing 2 you can see exactly what will be instantiated (and what you will be charged for) when you use Thing 2 to create an application. This might be an implementation detail, but nCAMP will refuse to attempt to instantiate an application from a Thing 2 that has artifact:requirements:fulfillment's without an href because this, to nCAMP, means that you have uploaded a Thing 1 that had requirements that nCAMP either didn't understand or was unable to match to an existing service.

I think Thing 2's need to be exposed at the API level because they support the following (IMP important) use case:

1.) Consumer POSTs a PDP to assembly_factory with the intent of instantiating the described application.

2.) The Provider processes the camp.yaml (Thing 1) and finds that there are either requirements that the Provider doesn't understand (unrecognized 'artifact:requirements:type' attribute) or whose characteristics don't match any of the services available to the Consumer.

3.) The Provider creates a plan resource (Thing 2) and responds to the POST request with an error (can't create the app) and reference to the newly created Thing 2.

4.) Consumers GETs Thing 2 and (hopefully) figures out what went wrong and which service they want to use for the affected artifact. Consumer updates Thing 2 with appropriate artifact:requirements:fulfillment:href values.

5.) Consumer POSTs reference to updated Thing 2 to assembly_factory and successfully instantiates application.

I think this is a likely use case for Consumers transferring their apps from one Provider to another. I've done similar things when moving a test app from Heroku to Engine Yard, CloudBees, etc. except, of course, there was no uniform API for doing it. The point is that you shouldn't make the Consumer re-upload all of their artifacts with every attempt to work out the artifact-to-service bindings.

> 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: 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)