[
https://issues.apache.org/jira/browse/ARIA-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15957076#comment-15957076
]
ASF GitHub Bot commented on ARIA-92:
------------------------------------
Github user tliron commented on a diff in the pull request:
https://github.com/apache/incubator-ariatosca/pull/95#discussion_r109940731
--- Diff: aria/modeling/service_instance.py ---
@@ -180,6 +181,16 @@ def validate_capabilities(self):
satisfied = False
return satisfied
+ def find_hosts(self):
--- End diff --
That's not true: this phase will need be run every time there is a change
in the topology. This is part of the reason I don't think `instantiation` is
the right name for this module we talk about, since it would actually be used
in many cases after instantiation.
> Execution plugin operations default mappings
> --------------------------------------------
>
> Key: ARIA-92
> URL: https://issues.apache.org/jira/browse/ARIA-92
> Project: AriaTosca
> Issue Type: Story
> Reporter: Ran Ziv
> Assignee: Tal Liron
>
> The execution plugin serves as the default plugin, i.e. if no other plugin
> was specified, it'll be used to execute scripts in operations.
> These scripts will currently only execute locally. The execution plugin also
> supports running scripts on remote machines (via SSH).
> One option is to have the parser recognize whether the node in question is
> contained inside a host node, in which case the script should be executed
> remotely (by default, yet overridable by specifying the full plugin operation
> mapping), and if not then it should be executed locally.
> Another option is to have the user specify it using special syntax, e.g.:
> "local > script.sh" and "remote > script.sh"
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
