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:comment-tabpanel&focusedCommentId=36882#comment-36882 ] 

Alex Heneveld commented on CAMP-168:

The `requirement_type` is a string which indicates to the CAMP server what logic to apply to satisfy the containing RequirementSpecification when matching the artifact with services.

The spec does not do a good job of explaining this.  I don't think renaming it will help.

Another paragraph or two in section 4.3.6 is needed at the least, and perhaps also some concrete `RequirementSpecification` `requirement_type` examples.

> 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

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