[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (CAMP-153) Two approaches to identify services in a DP?
[ http://tools.oasis-open.org/issues/browse/CAMP-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=36401#action_36401 ]
Adrian Otto commented on CAMP-153:
----------------------------------
Consider the two current formats for the same use case today:
=== FORMAT ONE ===
Request:
POST /plans HTTP/1.1
Host: api.solum.io
Content-Type: application/x-yaml
Content-Length: ...
# Adrian's Example 1 (EX1) - Make a Plan for building a Python application
camp_version: CAMP 1.1
artifacts:
-
name: My Python App
artifact_type: solum_git_pull
content: { href: http://github.com/some/project }
-
requirements:
-
requirement_type: solum_git_pull
solum_language_pack: 123abab-456abab-bab789-478459
fulfillment: id:build # See "Build Service" in services section below
services:
-
name: Build Service
id: build
href: http://api.solum.io/services/7
Resonse:
HTTP/1.1 201 Created
Location: http://api.solum.io/plans/1
=== FORMAT TWO ===
Request:
POST /plans HTTP/1.1
Host: api.solum.io
Content-Type: application/x-yaml
Content-Length: ...
# Adrian's Example 1 (EX1) - Make a Plan for building a Python application
camp_version: CAMP 1.1
artifacts:
-
name: My Python App
artifact_type: solum_git_pull
content: { href: http://github.com/some/project }
-
requirements:
-
requirement_type: solum_git_pull
solum_language_pack: 123abab-456abab-bab789-478459
fulfillment:
name: Build Service
id: build
href: http://api.solum.io/services/7
Resonse:
HTTP/1.1 201 Created
Location: http://api.solum.io/plans/1
Currently both of these formats are legal. Upon filing this issue, I felt that having two ways of doing the same thing would lead to additional complexity in the spec and related implementations. However, there is a good reason for having two expressions of this. It's a way to hint to the model interpreter that there should be ONE instance of the service used by multiple artifacts. That's why using a fulfillment id makes sense. When you want MULTIPLE instances of the service, you can list them individually. That use case justifies both of the formats.
I plan to move to CNA.
> Two approaches to identify services in a DP?
> --------------------------------------------
>
> Key: CAMP-153
> URL: http://tools.oasis-open.org/issues/browse/CAMP-153
> Project: OASIS Cloud Application Management for Platforms (CAMP) TC
> Issue Type: Bug
> Components: Spec
> Environment: CAMP Version 1.1 Draft 32 (dated: 5 December 2013).
> Reporter: Martin Chapman
> Assignee: Adrian Otto
> Priority: Minor
>
> This is 2) from https://lists.oasis-open.org/archives/camp-comment/201312/msg00000.html
> "
> 2) Is there a reason why there should be two approaches to identify services in a DP?
> Example 4 in Section 4.2.2.1 demonstrates one approach. In this the "service" section
> is not explicitly called out. It is defined under the "fulfillment" section which
> is hidden under the "RequirementType" relation.
> Example 5 demonstrates second approach. In this the "services" section is explicitly called out.
> I feel that services should be a first class entity of a DP, and providing an abstraction to
> explicitly identify them would make that status clear. Therefore, approach shown in example 5
> is better than that in example 4, imo. Is there any reason to keep both approaches?
> If not, can the spec be prescriptive about one approach (my vote is for approach in example 5)."
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]