RE: [tosca] operation implementations

Hi Tal,

We already have interface types and artifact types. What functionality is missing that requires the introduction of operation types?
The problem with âget_artifactâ is that it returns a path name that is only valid within the context of the orchestrator. If you pass that path name to a script that needs to be run on a remote machine, then that path name will be invalid on that remote machine.

Thanks,

Chris

From: Tal Liron <tliron@redhat.com>
Sent: Saturday, March 13, 2021 12:21 PM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] operation implementations

On Fri, Mar 12, 2021 at 5:59 PM Chris Lauwers <lauwers@ubicity.com> wrote:

Yes, we should definitely discuss this, but Iâm not sure what other options there are for defining operation implementations. Theyâre either defined using artifacts (our current approach), or they must be defined directly in the TOSCA language somehow. I believe that as a general rule, we should avoid adding implementation-specific constructs to the TOSCA language. Do you see alternative mechanisms?

I proposed a rough "operation type" grammar a while ago (2 years ago?). I still think it's the right approach and hope we can revisit it. We need a better grammar for creating an interface/membrane with orchestrators. I also think notifications need to be more powerful and allow for proper event definitions ("policy triggers" are far too narrowly defined).

Support for artifacts can be handled, I think, with the get_artifact function where appropriate. Note that this function is very poorly defined, still...

tosca message