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

Gilbert Pilz commented on CAMP-201:
-----------------------------------

This proposal essentially splits our current notion of "a type definition" into two separate, but related concepts - an actual type definition (that defines what every instance of a particular CAMP resource type looks like) and an instance definition (that defines what a particular instance of a CAMP resource looks like). The first concept can say nothing about the Consumer's ability to change mutable attributes, the second concept can (and must). There are two places you will see "actual type definitions". One of them is in the platform-level type_definition collection referenced by the "platform resource" and the other is referenced by the "collection_type" attribute of every collection resource. Meanwhile we can expect that the "type_definition" attribute of every individual resource will reference an "instance definition".

It seems that we may be opening ourselves to interoperability problems by using a single resource type (type_definition) to function as both an "actual type definition" and an "instance definition". For example if, as a Consumer, I dereference the "collection_type" attribute of the "assembly_factory resource" (which gets me a "type_definition resource"), dereference its "attribute_definition_collection" attribute (which gets me a "attribute_definition collection") and notice that the attribute definition for the "name" attribute has "consumer_mutable": true, does that mean I can modify the "name" attribute of every assembly resource in the assembly factory? And how would I model a situation in which I, the Consumer, can see 10 assemblies in the assembly factory, three for which I am allowed to change their names and seven for which I am not?

It seems to me that there are two ways of addressing this; one of them kludgy and the other adds complexity. In the kludgy way we can add additional text where we describe the platform-level type_definition collection and the collection.collection_type attribute to say "the type_definition resources reference from this attribute SHALL NOT reference attribute_definitions that define the "consumer_mutable" attribute" (in other words - you aren't allowed to have an opinion at this level). In the complicated way we split the current type_definition resource into two serpated resources (e.g. type_definition and intance_definition). The weird thing is, these two types wouldn't be different. It's just that one of them (instance_definition) is allowed to reference attribute_definitions that may indicate consumer mutability and the other (type_definition) is not.

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