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

Hi all, As I said last time, I think we really need to compile a list of everything everyone has brought up and organize it in some kind of spreadsheet or other TODO list. It doesn't mean we have to resolve all the topics or resolve them for TOSCA 2.0. But I just want to make sure we're keeping track. This is what I came up with, in no particular order. Feel very free to add more! What to do with "occurrences" keyword in requirements and capabilities, at both the node type and node template levels Automatically assign requirements (at the template) if the lower bound of occurrences is >0 CSAR: tarball (streaming) formats Packaging profiles as ... CSARs? Would this affect the metadata? (e.g. should the CSAR metadata contain the canonical namespace for the profile?) What do do with get_operation_output Profiles and versioning; individual types and versioning Suggested convention for profile naming Clarify special case of "in_range" function on "range" built-in type Graph traversal language for get_property and get_attribute Function notation: prefix character Spec's opinion on custom functions: special error messages? General purpose _expression_ language for TOSCA (with graph support)? See: Gremlin, GraphQL Should the parser calculate the data type for expressions in advance as part of parsing validation? Can it? Suggest regular _expression_ engine for portability? (suggestion: PCRE) Allow interfaces on capabilities? Do we need groups or can they be replaced with policies? Can we get rid of (imperative) workflows? Do we need to replace them with topology-wide event definitions? Can we get rid of policy triggers How about an "any" built-in type for arbitrary YAML-compatible data structures? (I call this ARD ) Are we removing "json" and "yaml" built-in types? What to do with the "schema" constraint? Artifacts: Can they only be attached to nodes? Can they be attached to topologies? How about relationships, groups, policies, etc.? And to interfaces? Generating multiple node templates by templatizing the template name? Rethink what we want to achieve in TOSCA with policies (look at policy language like OPA's Rego ) Support more complex constraint logic, inspired by OpenAPI The case sensitivity issue with scalar-unit.bitrate

thanks for pulling this together, this is a great list! I add: * How to retrieve outputs from operations (1.3 spec text discussion isn't actually implementable) * Passing structured data to operation (e.g. how to interpret json in environment variables) * Add a way to mark attributes as identifiers to uniquely identify an instance (enables discovery and provides a mechanism for dealing with multiplicity of instances) Adam á On Tue, Dec 14, 2021 at 9:14 AM Tal Liron < tliron@redhat.com > wrote: Hi all, As I said last time, I think we really need to compile a list of everything everyone has brought up and organize it in some kind of spreadsheet or other TODO list. It doesn't mean we have to resolve all the topics or resolve them for TOSCA 2.0. But I just want to make sure we're keeping track. This is what I came up with, in no particular order. Feel very free to add more! What to do with "occurrences" keyword in requirements and capabilities, at both the node type and node template levels Automatically assign requirements (at the template) if the lower bound of occurrences is >0 CSAR: tarball (streaming) formats Packaging profiles as ... CSARs? Would this affect the metadata? (e.g. should the CSAR metadata contain the canonical namespace for the profile?) What do do with get_operation_output Profiles and versioning; individual types and versioning Suggested convention for profile naming Clarify special case of "in_range" function on "range" built-in type Graph traversal language for get_property and get_attribute Function notation: prefix character Spec's opinion on custom functions: special error messages? General purpose _expression_ language for TOSCA (with graph support)? See: Gremlin, GraphQL Should the parser calculate the data type for expressions in advance as part of parsing validation? Can it? Suggest regular _expression_ engine for portability? (suggestion: PCRE) Allow interfaces on capabilities? Do we need groups or can they be replaced with policies? Can we get rid of (imperative) workflows? Do we need to replace them with topology-wide event definitions? Can we get rid of policy triggers How about an "any" built-in type for arbitrary YAML-compatible data structures? (I call this ARD ) Are we removing "json" and "yaml" built-in types? What to do with the "schema" constraint? Artifacts: Can they only be attached to nodes? Can they be attached to topologies? How about relationships, groups, policies, etc.? And to interfaces? Generating multiple node templates by templatizing the template name? Rethink what we want to achieve in TOSCA with policies (look at policy language like OPA's Rego ) Support more complex constraint logic, inspired by OpenAPI The case sensitivity issue with scalar-unit.bitrate

Small emphasis that I forgot to add to this list -- It's true that we've "resolved" some of these issues in conversations in the TOSCA TC. But that's not enough, we also have to update the spec. :) So the point is to track all topics until they are "done". On Tue, Dec 14, 2021 at 11:14 AM Tal Liron < tliron@redhat.com > wrote: Hi all, As I said last time, I think we really need to compile a list of everything everyone has brought up and organize it in some kind of spreadsheet or other TODO list. It doesn't mean we have to resolve all the topics or resolve them for TOSCA 2.0. But I just want to make sure we're keeping track. This is what I came up with, in no particular order. Feel very free to add more!

Two more items to add to the TODO list: 1. We need an explicit, deterministic algorithm for satisfying requirements, down to alphabetical ordering of capabilities and node template names. I suggest that the spec actually contain pseudo-code that implementors can build upon. Doing so will also help us ground the discussion. 2. "Dangling requirements". I remain opposed to this proposed feature, but if it is to be included then it must be specced out in the requirement satisfaction algorithm mentioned above.