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-168) requirment_type is confusing for implementers


     [ https://tools.oasis-open.org/issues/browse/CAMP-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Chapman  updated CAMP-168:
---------------------------------

    Resolution: 
From 7th May 2014
      Motion: tom moves to accept gil's proposal to CAMP-168 and resolve it, 2nd Alex.
            gil will open issue for versioning
      approved w/o objs.  168 resolved.
https://www.oasis-open.org/apps/org/workgroup/camp/download.php/52683/camp-spec-v1.1-wd40-168.doc

> requirment_type is confusing for implementers
> ---------------------------------------------
>
>                 Key: CAMP-168
>                 URL: https://tools.oasis-open.org/issues/browse/CAMP-168
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: Spec
>            Reporter: Adrian Otto
>
> Solum is in the process of implementing a CAMP inspired model interpreter. The job of this component is to take Plan Files and PDP content as input, and auto-wire requirements to services, generate an orchestration template, and initiate the deployment of the assembly in accordance with the description in the Plan File.
> In order to do wiring, there needs to be a programmatic matching of artifact requirements and service capabilities. Because the requirement_type is described as a *relationship* to be defined by the implementer, this makes the matching objective seem impossible.
> Possible solutions might be to rename requirement_type to relationship_type, or change requirement_type to requirement_parameter_string, and provide guidance for how to use key/value pairs to inform a model interpreter to match those key/value pairs with characteristics from services. This would be much more useful, and help make the spec more crisp on this subject.



--
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]