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-201) Consumer mutability of attribributes and attribute types

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

David Laurance commented on CAMP-201:

A few separate points:
1. I completely agree that query-able metadata is needed to support consumers' ability to configure themselves.  Any solution needs to provide that.
2. Our proposal as I understand it is to separate out "mutable" from "consumer-mutable."  I think that separation is helpful and adds clarity.
3. In our discussion I think we have broad agreement that the <I>mechanism</I> for consumers to change values is a POST operation.

From these three points, I observe that "consumer mutability" depends upon three factors:
1. attribute mutability - if it can't be changed, then it can't be changed by a consumer
2. platform support for a suitable POST API
3. authorization to use that POST API

Setting aside the question of authorization for the moment, I think <I>consumer mutability</I> really comes down to the questions of (1) what POST APIs are supported, and (2) what attribute(s) can be changed by each supported API.  

Since we agree that we want a consumer to be capable of configuring itself, then we need metadata about supported APIs, including (1) and (2) above.  This, in effect, will answer the question: "What can be changed by a consumer?"

In self-configuring, it's possible that a consumer must consider underlying mutability as well.  That is, it may be that there is a suitable API to change attribute <B>foo</B>, but for a specific resource <B>bar</B>, that attribute is not mutable.  That is, the consumer may need to treat the same attribute differently for different resources, and would thus require access to the resource (instance) metadata.  But that is "mutable," not "consumer-mutable."

> 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

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