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] Commented: (CAMP-30) Parameter Scheme


    [ http://tools.oasis-open.org/issues/browse/CAMP-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32720#action_32720 ] 

Alex Heneveld commented on CAMP-30:
-----------------------------------

Good progress, and good discussion today.  My tuppence worth:

* I'm strongly in favour of parameterDefinition instead of "temporary"

* I'm okay with accepting attributeDefinitions at creation time, to avoid proliferation of duplication in parameterDefinition namespace
   -- although personally i think that this duplication might be simpler than trying to figure out which attributes are also parameters

IOW i prefer the *simple* model where _parameters_ are used at creation time; _attribute_ patches can be done in the usual way thereafter; and in some cases parameters correspond to attributes (in the same way a parameter in a java class constructor will often match a field in the class)

Gil raises the compelling use case of setting a name.  I would say the spec supplies a parameterDefinition for name to handle this.

Finally I'd strongly suggest we say that where these creation-time parameters (and perhaps attributes) match with attributes that the behaviour will normally be analogous to doing a PATCH to that attribute.  The subtle different here is that this does not (I don't think) require that the attribute value actually be changed to requested value (for instance if a value has to be rounded, or the implied state transition is not possible) -- although in the case of metadata (name, tags, etc) it should be.


> Parameter Scheme
> ----------------
>
>                 Key: CAMP-30
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-30
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Improvement
>          Components: Spec
>            Reporter: Adrian Otto
>            Assignee: Adrian Otto
>            Priority: Critical
>
> Create a well defined template parameter scheme that can be used to express special labels in template resource attributes that are used for supplying values upon instantiating entities using the template. In addition to a template parameter label, we also need a standard mechanism to specify values for the labels when using the API.
> This feature can be used for supplying a unique name to an Application Assembly at the time it is created and started. This would allow multiple Application Assemblies to be created from the same template to run concurrently, and offer a way to easily tell them apart from each other. The scheme should be flexible such that it works for Component Templates as well, so that it can be used for passing in configuration parameters that are employed by a downstream configuration management system.

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