[OASIS Issue Tracker] (TOSCA-185) Instance model

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

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

Matthew Rutkowski  commented on TOSCA-185:
------------------------------------------

Hi Jacques,  I have been reading your comments, but I do not believe we are going to abandon the attributes and get_attribute approach where the template (while being orchestrated) has resources (in the dependency graph)  that are able to access attributes of other resources that have already been instantiated (i.e. resource instances).  This approach has proven to work well in our current reference impl. and the code works well for get_attribute as coded by Gigaspaces.  In addition, it is possible, and we have examples where we have attributes where there are no properties.  In fact, you mentioned ip address and that is exactly what we have for Compute node type where the network assigns IPs to ports to instances allocated on the network they are deployed on.  You will see that we are trying to "deprecate" anywhere we may have IP addresses coded as properties (or remove them entirely) and encourage using the "HOST" keyword on get_attribute() to retrieve the IP address assigned to the host the software component (app) is hosted on.  

The short of it is I do not see us abandoning attributes and trying to use only properties and trying to somehow return an instance ID.  This approach has many issues of its own as there is not one instance ID, there are many instances as scaling occurs and during different lifecycle operations we would need individual resource instance IDs.  It is better not to require that orchestrators publish these things as we can achieve the same thing now implicitly via attributes and its methods.  That is, as we have it no, no instance ID is needed since all get_attribute functions are relative to the instance they are being invoked/executed in; the orchestrator should know what this is no matter how many instances of the model there are (via scaling).

REST is not violated as properties represent the desired state and attributes the actual state of the resources within an instance (i.e., relative to the instance they are being invoked within).  External REST to the entirety of the running (instance) model have not yet been specified, but would assume to have access to all instance IDs, resource IDs (relative to the instances) and the ability to invoke lifecycle operations (i.e., TOSCA interfaces) which would be coded to act relative to attributes available within their instances.

> Instance model
> --------------
>
>                 Key: TOSCA-185
>                 URL: https://issues.oasis-open.org/browse/TOSCA-185
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: Improvement
>          Components: Profile-YAML
>            Reporter: Derek Palma
>            Assignee: Jacques Durand 
>
> We have reached a point where we need to define an instance model. We should consider describing the following:
> 1) How a template causes node and relationship instances to be created
> 2) The schemas of node and relationship instances based on their respective types
> 3) The ability of a TOSCA runtime to add its own properties to an instance
> 4) The ability of a node or relationship operations to set attributes
> 5) Navigation of the instance model
> 6) Navigation from the instance to their respective templates and types.
> 7) Serialization of the instance model in YAML



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