[OASIS Issue Tracker] (CAMP-168) requirment_type is confusing for implementers

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

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

Gilbert Pilz commented on CAMP-168:
-----------------------------------

Added a proposal that seeks to clear up some of the confusion about RequirementSpecifications. Although we have agreed that we need some sort of primer to explain some of these concepts more fully, the main spec needs to stand on its own. I found it necessary to add a small amount of "primerish" material to make this possible.

> 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.1.1#6155)