OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

Hi, This would not be a major change, but i it would be good to have some example on how this would be useful. Basically it would restrict nodes to be of that type. I don't see any harm even if nodes can be of that type. Br/C Sent from Workspace ONE Boxer On 18 Feb 2020 18:53, Tal Liron <tliron@redhat.com> wrote: We had an interesting discussion today in the ad-hoc group about some of the finer aspects of object-oriented derivation. One thing that came up is that in many objected-oriented architectures it is useful to have abstract types, that cannot be "instantiated", but are used as contracts for a system interacting with instances of the derived types. Due to the limitation of OOP, in some cases it might even be necessary to get around the limitations of single-parent derivation. Indeed, in the Simple Profile 1.3 we currently have an Abstract.Compute type. My thought is this: bake this into the grammar. Add an "abstract" keyword that, if true, would ensure that the type cannot be used for a node template. In other words, it exists only for it to be derived from. Example: node_types:   Machine:     abstract: true     properties: ...   Server:     derived_from: Machine     properties: ...     # default is "abstract: false" topology_template:   node_templates:     server1:       type: Machine # this would result in an error!     server2:       type: Server # this is valid! This keyword can also exist in group types and policy types, which like node types can potentially be "instantiated" in the topology template. For capability and relationship types it is more complicated, because they are not quite "insantiable" in the same way.

This would also create confusion with the current concept of “abstract” node templates that need to be implemented using substitution mapping.   Chris     From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> On Behalf Of Calin Curescu Sent: Monday, February 24, 2020 8:49 AM To: tosca@lists.oasis-open.org; Tal Liron <tliron@redhat.com> Subject: [tosca] "abstract" node types   Hi,   This would not be a major change, but i it would be good to have some example on how this would be useful.   Basically it would restrict nodes to be of that type. I don't see any harm even if nodes can be of that type.   Br/C   Sent from Workspace ONE Boxer   On 18 Feb 2020 18:53, Tal Liron < tliron@redhat.com > wrote: We had an interesting discussion today in the ad-hoc group about some of the finer aspects of object-oriented derivation. One thing that came up is that in many objected-oriented architectures it is useful to have abstract types, that cannot be "instantiated", but are used as contracts for a system interacting with instances of the derived types. Due to the limitation of OOP, in some cases it might even be necessary to get around the limitations of single-parent derivation. Indeed, in the Simple Profile 1.3 we currently have an Abstract.Compute type.   My thought is this: bake this into the grammar. Add an "abstract" keyword that, if true, would ensure that the type cannot be used for a node template. In other words, it exists only for it to be derived from. Example:   node_types:   Machine:     abstract: true     properties: ...     Server:     derived_from: Machine     properties: ...     # default is "abstract: false"   topology_template:   node_templates:     server1:       type: Machine # this would result in an error!       server2:       type: Server # this is valid!   This keyword can also exist in group types and policy types, which like node types can potentially be "instantiated" in the topology template.   For capability and relationship types it is more complicated, because they are not quite "insantiable" in the same way.