TOSCA TODO list

[Tal Liron <tliron@redhat.com>]

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!

1. What to do with "occurrences" keyword in requirements and capabilities, at both the node type and node template levels
2. Automatically assign requirements (at the template) if the lower bound of occurrences is >0
   
3. CSAR: tarball (streaming) formats
4. Packaging profiles as ... CSARs? Would this affect the metadata? (e.g. should the CSAR metadata contain the canonical namespace for the profile?)
   
5. What do do with get_operation_output
6. Profiles and versioning; individual types and versioning
   
7. Suggested convention for profile naming
8. Clarify special case of "in_range" function on "range" built-in type
9. Graph traversal language for get_property and get_attribute
10. Function notation: prefix character
    
11. Spec's opinion on custom functions: special error messages?
12. General purpose _expression_ language for TOSCA (with graph support)? See: Gremlin, GraphQL
    
13. Should the parser calculate the data type for expressions in advance as part of parsing validation? Can it?
    
14. Suggest regular _expression_ engine for portability? (suggestion: PCRE)
15. Allow interfaces on capabilities?
16. Do we need groups or can they be replaced with policies?
17. Can we get rid of (imperative) workflows? Do we need to replace them with topology-wide event definitions?
    
18. Can we get rid of policy triggers
19. How about an "any" built-in type for arbitrary YAML-compatible data structures? (I call this ARD)
    
20. Are we removing "json" and "yaml" built-in types?
21. What to do with the "schema" constraint?
22. Artifacts: Can they only be attached to nodes? Can they be attached to topologies? How about relationships, groups, policies, etc.? And to interfaces?
    
23. Generating multiple node templates by templatizing the template name?
24. Rethink what we want to achieve in TOSCA with policies (look at policy language like OPA's Rego)
    
25. Support more complex constraint logic, inspired by OpenAPI
26. The case sensitivity issue with scalar-unit.bitrate