[
https://issues.apache.org/jira/browse/ARIA-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Ziv updated ARIA-151:
-------------------------
Description:
The execution plugin will currently run scripts either remotely (on hosts
managed by ARIA) or locally (on the machine running ARIA), depending on whether
the script was declared under an interface of a node which is/has a host or not.
Seeing as most TOSCA types require a {{host}}, it'll be useful to have the
ability to tell the plugin explicitly to execute the code locally.
Some ideas on how this may be done:
- a {{dependency}} definition, similar to other execution-plugin configuration
parameters - however, this would require a per-operation configuration, which
can get quite verbose on nodes with several script operations.
- a special host type (e.g. {{LocalHost}}) which inherits from TOSCA's root,
and is recognized automatically by the execution-plugin.
- a special property on the executing node or the host node? That seems
problematic as it won't be relevant to standard types.
- special syntax in the operation implementation line (e.g. {{local >
script.sh}})
It might also be worth mentioning that the execution-plugin further supports an
additional mode of operation - simplified remote execution of "commands", which
are written inline in the service template. It might be better to come up with
a solution which simply lets the user decide (if one desires; the default
behavior should always be simply what's expected) among local execution, remote
execution (possibly on a different host?), and simplified commands mode
execution.
was:
The execution plugin will currently run scripts either remotely (on hosts
managed by ARIA) or locally (on the machine running ARIA), depending on whether
the script was declared under an interface of a node which is/has a host or not.
Seeing as most TOSCA types require a {{host}}, it'll be useful to have the
ability to tell the plugin explicitly to execute the code locally.
Some ideas on how this may be done:
- a {{dependency}} definition, similar to other execution-plugin configuration
parameters - however, this would require a per-operation configuration, which
can get quite verbose on nodes with several script operations.
- a special host type (e.g. {{LocalHost}}) which inherits from TOSCA's root,
and is recognized automatically by the execution-plugin.
- a special property on the executing node or the host node? That seems
problematic as it won't be relevant to standard types.
It might also be worth mentioning that the execution-plugin further supports an
additional mode of operation - simplified remote execution of "commands", which
are written inline in the service template. It might be better to come up with
a solution which simply lets the user decide (if one desires; the default
behavior should always be simply what's expected) among local execution, remote
execution (possibly on a different host?), and simplified commands mode
execution.
> Support local script execution on hosted nodes
> ----------------------------------------------
>
> Key: ARIA-151
> URL: https://issues.apache.org/jira/browse/ARIA-151
> Project: AriaTosca
> Issue Type: Story
> Reporter: Ran Ziv
>
> The execution plugin will currently run scripts either remotely (on hosts
> managed by ARIA) or locally (on the machine running ARIA), depending on
> whether the script was declared under an interface of a node which is/has a
> host or not.
> Seeing as most TOSCA types require a {{host}}, it'll be useful to have the
> ability to tell the plugin explicitly to execute the code locally.
> Some ideas on how this may be done:
> - a {{dependency}} definition, similar to other execution-plugin
> configuration parameters - however, this would require a per-operation
> configuration, which can get quite verbose on nodes with several script
> operations.
> - a special host type (e.g. {{LocalHost}}) which inherits from TOSCA's root,
> and is recognized automatically by the execution-plugin.
> - a special property on the executing node or the host node? That seems
> problematic as it won't be relevant to standard types.
> - special syntax in the operation implementation line (e.g. {{local >
> script.sh}})
> It might also be worth mentioning that the execution-plugin further supports
> an additional mode of operation - simplified remote execution of "commands",
> which are written inline in the service template. It might be better to come
> up with a solution which simply lets the user decide (if one desires; the
> default behavior should always be simply what's expected) among local
> execution, remote execution (possibly on a different host?), and simplified
> commands mode execution.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
