[OASIS Issue Tracker] (CAMP-201) Consumer mutability of attribributes and attribute types

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

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

Anish Karmarkar commented on CAMP-201:
--------------------------------------

The reason to have the metadata that is query-able by a consumer is so that one doesn't have to code in that information. The consumer can be built to be more generic and metadata is processed at runtime to determine what is possible. So all things being equal, I'm not terribly in favor of stating in the spec in words what is mutable and what isn't. I would rather include that in the metadata. I see two ways out:
1) remove it completely. In the absence of an extension or out-of-channel information, consumers can try PUT/PATCH and it may or may not fail.
2) leave it in as a concept, but specify it (mutable=true/false) only for those cases where there is complete agreement on whether it is true (eg: description) or false (eg: URI). + specific a reasonable default ("false" seems to be the right choice to me).

I also do want to ensure that platforms have the freedom to allow PUT/PATCH where it is appropriate and not force them to use POST in every case.

> Consumer mutability of attribributes and attribute types
> --------------------------------------------------------
>
>                 Key: CAMP-201
>                 URL: https://issues.oasis-open.org/browse/CAMP-201
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: Spec
>    Affects Versions: 1.2
>            Reporter: Anish Karmarkar
>            Assignee: Anish Karmarkar
>            Priority: Critical
>
> The spec currently defines consumer mutability of an attribute in the attribute type definition. Questions have been raised about whether that is appropriate. Few scenarios that complicate this:
> 1) Collection type 'items' attribute may be mutable or not depending on the kind of collection.
> 2) the consumer mutability of an attribute may depend on an instance not the type. Moving this to the type necessitates unnecessary invention of additional types
> 3) the mutability of an attribute may depend on other factors such as authorization/credentials of the consumer or it may change with time (because changing the attribute value may make something else inconsistent).
> Issues 180, 196, and 199 depend on resolution of this issue.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)