RE: [tosca] TOSCA TODO list

Hi Paul,

Priorities are driven by the TC members, so please feel free to push your personal preferences 😊

Thanks,

Chris

From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> On Behalf Of Paul Jordan
Sent: Tuesday, December 14, 2021 10:03 AM
To: tosca@lists.oasis-open.org
Subject: Re: [tosca] TOSCA TODO list

I understand that this is a list of things which have already been identified by the TC. It should not be used to push personal preferences on the future direction of TOSCA. However here are a couple of things I've come across which may have been considered or might be worth looking at in the future:

* Can/should requirements be refined?

* Should a relationship definition be allowed to refer to properties of a target node type before the type of the node has been declared/resolved? If not then the Node clause should be documented as required in that case.

Paul Jordan

On 14/12/2021 17:31, Tamburri, Damian wrote:

Hey guys!!! would you be able to put together a 4-pager about those bullets and the rationale/plans towards them? that would amount to an awesome submission to present to the FIST workshop!!! indeed 4 pages in this format would be more than super :)

just food for thought!!!

D.

Damian Andrew Tamburri, Ph.D.

Associate Professor

TU/e - JADS -
https://www.jads.nl/
Sint Janssingel 92, sâHertogenbosch

Room 2.18, 2nd Floor

Email: d.a.tamburri@tue.nl
Cell: +39 3491279924
Web: https://www.researchgate.net/profile/Damian_Tamburri

Executive Director, Jheronimus Academy Data & Engineering (JADE) Lab
Secretary, OASIS âTopology and Orchestration for Cloud Applicationsâ (TOSCA) Standard Technical Committee
Secretary, IFIP - WG 2.14 / 6.12 / 8.10 on Service-Oriented Systems

Associate Editor & Online Presence Director, ACM Transactions on Software Engineering & Methodology (TOSEM)

On 14 Dec 2021, at 18:26, adam souzis <adam@souzis.com> wrote:

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

tosca message