[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=61260#comment-61260 ] 

Michael Norman commented on CAMP-201:
-------------------------------------

So I agree that the use of POSTs are correct.  I know there has been some consternation on the calls about the fact that we might be playing fast and loose with the semantics of HTTP, but there should be no concern about the use of POST for deployment or creation of plans - these are creating entities not changing them. The use of POST on an Operation to do something to an instantiated entity is also correct because the operation cannot be assumed to be idempotent.  Changing the name of an Operation is, by contrast, idempotent so this would be a PUT.

I can't see anything on the instantiated entities other than name, tags, and description that needs to be changed. However, I believe that  the spec saying that certain attributes and/or certain entity types are mutable or immutable is fundamentally the wrong way to go.  The client does not read the spec and/or the spec of any extensions it comes across. It reads the metadata in the API and it needs the mutability or otherwise of attributes to be expressed via the API. Also, once you introduce ACL, the client can't assume the information in the spec is correct for the particular entity it is dealing with. Fundamentally the API needs a mechanism for saying to the client "this actor at this point in time can change this attribute on this entity to one of these values". So I suggest we say nothing in the spec about mutability other than providing this mechanism. 

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