[OASIS Issue Tracker] Commented: (TOSCA-116) Normative Base Types Proposal (Node/Relationship) - derived from experience with SugarCRM private interop.

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

    [ http://tools.oasis-open.org/issues/browse/TOSCA-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33839#action_33839 ] 

Frank Leymann  commented on TOSCA-116:
--------------------------------------

I have a bunch of comments on Matt's presentation:

Slide 3: What is the assumption behind defining these states:  that the TOSCA container always knows them?  If this is the assumption, how can we rely on an operation returning corresponding state information to the TOSCA container?  Or is the assumption that lifecycle operations are always invoked via a TOSCA container (I don't believe that!)?  Even if it is invoked via a TOSCA container the hidden assumption is that from return codes of the operation the success of entering the corresponding state can be inferred. All these assumptions have to be clearly stated...

Slide 3:  What is the meaning of the color code (red vs black)?

Slide 3: It doesn't help to reference CIMI and Openstack as description. I need the text, and especially, I would assume that these descriptions are semantically equivalent?

Slide 3: I don't understand the description of the CompName attribute: "It is a property that can be matched via a requirement". If this a relevant for req/cap matchmaking, it should be defined as property of a capability. 

Slide 3: Versioning is a separate issue, thus, we should leave out the CompVersion attribute. What would be the semantics of CompVersion - just a string? Or is the intend to perform some sort of consistency checking in terms of versions that are compatible within a collection of node types of a topology template? Etc...

Slide 5: The definition is not reflected at all in the tables - e.g. how is availability specified (e.g. the availability class, the kind of guarantee given), how is scalability specified (e.g. auto-scaling properties)?  How is the "application processing capability" defined?  How is substitutability of tiers detected?

Slide 5:  I agree with your comment that a tier should define its capabilities in terms of what it can contain.

Slide 7: Meaning of the restrictions of NumCPUs?  

Slide 7: If one specifies an OS for a Compute, does it still make sense to define the OSContainerCap?  I mean the Compute than has already an OS - do we need to say that no other OS may be attempted to be installed there?

Slide 7: Description of Capability.OS is unclear to me.

Slide 10:  I assume that a Web Server has many properties (e.g. HTTP version supported; is it suitable for Java, C#,... programs;...)

Slide 10: I assume a Web Server has additional operations (e.g. deploy() of a Web application).

Slide 11: I don't understand what an "application with exported endpoints" is.

Slide 11: I don't think that having an Application Root Node Type makes sense at this stage.  While even a Web Application Node Type needs more clarification (i.e. is it something that can be deployed into a Web Server?), an Application Node Type is really abstract - we would need to distinguish between "application" and the rest of software, or don't we?

Slide 13: Do we subsume all kinds of DBMSs here (e.g. RDBMS, NoSQL, NewSQL, OODBMS,...)? Are we sure they can all be generalized into "DBMS"?  I recommend to focus on "RDBMS" here as discussed in the context of SugarCRM....

Slide 14: We need operations here, like Backup, Restore, Grant, Revoke.  Or do we ignore those operations because we did not need them for SugarCRM?  But we also added material that we didn't need for SugarCRM, i.e. we should list such important operations.  Also, these operations will prove that we do not only have provisioning and decommissioning in mind, but the whole spectrum of management of cloud applications. 

Slide 16: Don't we need to subtype into Block Store, BLOB Store, Key-Value Store,...?

Slide 19: The mechanism for composition that we have in TOSCA is the Boundary Definitions mechanics for Service Templates. 

Slide 20: This seems to be a stretch to me. Do we want to abstract such diverse Application Runtimes like JEE, .Net, CISC, Non-Fenced Stored Procedures,...? Does Application Runtime inherit from the very first Root Node Type?

Slide 22: I don't understand "abstract operations".  Do we want to substitute Source & Target Interfaces by that?  If we want, what about upward compatibility?<

Slide 23:  Each node is subject to becoming source or target of a relationship type. Thus, they should support the operations listed on the Root Relationship Type, which means that we should move the operations defined here to the Root Node Type. Also, I don't understand the semantics of these operations. 

Slide 24: We must indicate that Hosted_On does not only connect a ContainerReq and a ContainerCap, but that any Node Type that is a specialization of a Container can be target, and any other Node Type can be source of Hosted_On. 

Slide 25:  Similar comment like wrt Slide 24. 

Slide 25:  Here I am missing the Source Interfaces and Target Interfaces. 

Slide 25: The list of "known subclasses" is wrong. We define a Rel Type here, but no Req Type or Cap Type. 

Slide 27:  A very key aspect of specifying Rel Types is the specification of the order in which they have to be considered in a declarative processing of a topology template. I.e. which Rel Type takes precedence over another.  Also, we need to think about how this precedence order can be extended when other Rel Types are defined (which will happen in the field - if we don't believe this, there is no need to support the definition of Rel Types in TOSCA). 


> Normative Base Types Proposal (Node/Relationship) - derived from experience with SugarCRM private interop.
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: TOSCA-116
>                 URL: http://tools.oasis-open.org/issues/browse/TOSCA-116
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: Task
>          Components: Interop
>            Reporter: Matthew Rutkowski 
>
> This issue (task) will be used to propose and develop a set of normative, base node and relationship types that will evolve to support Interop. SC use cases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira