[
https://issues.apache.org/jira/browse/ARIA-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16009762#comment-16009762
]
Ran Ziv edited comment on ARIA-80 at 5/14/17 3:17 PM:
------------------------------------------------------
Option (1) has been implemented for now.
It currently only supports custom workflows code which come as resources of a
service-template, not as plugins.
See related issue for possible improvements.
was (Author: ran):
Option (1) has been implemented for now. See related issue for possible
improvements.
> Workflow plugins
> ----------------
>
> Key: ARIA-80
> URL: https://issues.apache.org/jira/browse/ARIA-80
> Project: AriaTosca
> Issue Type: Story
> Reporter: Ran Ziv
> Assignee: Ran Ziv
>
> API for supporting custom workflow plugins.
> The current plugin mechanism supports storing a workflow plugin's code.
> For the code to be accessible during a workflow execution, it needs to be
> loaded into the environment.
> One option would be to load it in the current environment. This should be
> fine for ARIA's CLI; however when used as an SDK this could prove problematic
> in cases where different workflow plugins have conflicting dependencies for
> example (although this might not be necessarily a common problem, due to the
> workflow's API being more strict when compared to an operation's API, i.e.
> less need for dependencies etc.)
> Another option would be to load and run the workflow code in yet another
> subprocess - which would mean a separate, clean environment for it to run in,
> similarly to the process executor's behavior - however, this could complicate
> things unnecessarily, and make it so that when a user wants to run a simple
> script they'd have to have 4 different processes running (CLI --> workflow
> execution process --> process executor / operation's process --> script's
> process)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
