[
https://issues.apache.org/jira/browse/ARIA-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16117254#comment-16117254
]
Ran Ziv commented on ARIA-334:
------------------------------
Sounds interesting. Is there a reason for having the policy type as
{{aria.Operation}} and then have a single {{configuration}} property though,
rather than having the policy type be {{aria.OperationConfig}} and then have
the properties themselves be the configuration?
> Policy for operation execution configuration
> --------------------------------------------
>
> Key: ARIA-334
> URL: https://issues.apache.org/jira/browse/ARIA-334
> Project: AriaTosca
> Issue Type: Story
> Reporter: Tal Liron
> Assignee: Tal Liron
>
> Our support for [using dependencies to configure operation
> execution|https://cwiki.apache.org/confluence/display/ARIATOSCA/Execution+Configuration]
> solves the technical problem, but it is very cumbersome to use in large
> templates.
> One solution is to use YAML macros (in the {{dsl_definitions}} section of the
> TOSCA template). But this is still awkward and ugly to have to insert the
> macro for every operation.
> The TOSCA way to do this is by policy. I suggest we support a new policy for
> operation execution, while *also* lettings user override those values locally
> per operation.
> Here's how it can be defined in the ARIA profile:
> {code}
> policy_types:
> aria.Operation:
> derived_from: tosca.policies.Root
> targets: [ tosca.nodes.Root, tosca.groups.Root ]
> properties:
> configuration:
> type: map
> entry_schema: string
> {code}
> You could then use it like so:
> {code}
> topology_template:
> policies:
> ssh:
> type: aria.Operation
> targets: [ bono, sprout, ralf, homer, homestead, vellum ]
> properties:
> configuration:
> ssh.user: { get_property: [ HOST, host, ssh.user ] }
> ssh.password: { get_property: [ HOST, host, ssh.password ] }
> ssh.address: { get_attribute: [ HOST, public_address ] }
> {code}
> What the above means is that for *all* operations on *all* interfaces of the
> target nodes (or groups) the above configuration parameters would be
> automatically applied (though local use of {{dependencies}} could override
> these values).
> The nice thing about this is that 1) it just needs to be defined once, and 2)
> it avoids our hacky {{dependencies}} notation.
> It might also make sense to add more properties to the policy for applying
> the policy only to specific interfaces or even specific operations and the
> target nodes. But that could possibly wait for a followup JIRA task.
> Note that the above example would also require us to fix intrinsic functions.
> As it stands, the parser would fail the above, because using the {{HOST}}
> keyword can only be used for properties inside a node or relationship. We
> would thus also need to allow for policies to use {{HOST}}, and assume it
> applies to the target node.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
