OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [tosca] operation implementations


On Mon, Mar 15, 2021 at 10:43 PM Chris Lauwers <lauwers@ubicity.com> wrote:
  • We already have interface types and artifact types. What functionality is missing that requires the introduction of operation types?
How is an RPC call (JSON-RPC, REST, etc.) to be implemented as an artifact? I don't see the relation. The idea is that exactly an operation type would define the structure of "implementation", which right now is a string or list of strings, which not only is very limited but also has no obvious semantic meaning. E.g. you are assuming that the implementation string represents an attached artifact name, but ... I very often use it for entirely different things for the various operations that I use.
Â
  • 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.
Right! But what if you want to run the operation on the remote machine? And if you do, what would be the execution mechanism? Agin, I can see an operation type as a way to clarify exactly how you want this operation to be evaluated and executed.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]