[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:all-tabpanel ]

Anish Karmarkar updated CAMP-201:
---------------------------------

    Proposal: 
Few ways we could deal w/ this:
1) No change. Instance specific mutability or authorization issues are deal with via a round trip and an HTTP error code.
2) Remove consumer mutability of the attribute from the spec
3) Leave the consumer mutability of attributes in the spec, but not define the values in the spec. Let platform impl decide. They may decide to leave it in the type off the platform or make it instance specific. HTTP caches work using the URL, an instance that points to the type will work just fine with HTTP caches.

-----
Based on the 2015-10-28 call, option (2) was acceptable. Proposal for option (2) is at https://www.oasis-open.org/committees/document.php?document_id=56855&wg_abbrev=camp

-----
Based on 2015-11-04 telcon, updated v2 proposal: https://www.oasis-open.org/committees/document.php?document_id=56859&wg_abbrev=camp
-----
Based on 2015-12-02 telcon, updated v3 proposal: https://www.oasis-open.org/committees/document.php?document_id=57080&wg_abbrev=camp
On 2015-12-02 telcon the TC agreed to have the following:
1) both mutability and consumer-mutability as metadata
2) this is associated at the instance level not type
3) The spec will not specify whether the values are true or false
4) It is the platform that decides the values and must provide that information to the consumer


  was:
Few ways we could deal w/ this:
1) No change. Instance specific mutability or authorization issues are deal with via a round trip and an HTTP error code.
2) Remove consumer mutability of the attribute from the spec
3) Leave the consumer mutability of attributes in the spec, but not define the values in the spec. Let platform impl decide. They may decide to leave it in the type off the platform or make it instance specific. HTTP caches work using the URL, an instance that points to the type will work just fine with HTTP caches.

-----
Based on the 2015-10-28 call, option (2) was acceptable. Proposal for option (2) is at https://www.oasis-open.org/committees/document.php?document_id=56855&wg_abbrev=camp

-----
Based on 2015-11-04 telcon, updated v2 proposal: https://www.oasis-open.org/committees/document.php?document_id=56859&wg_abbrev=camp


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