ariatosca-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tal Liron (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (ARIA-334) Policy for operation execution configuration
Date Fri, 28 Jul 2017 23:25:00 GMT

     [ https://issues.apache.org/jira/browse/ARIA-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Tal Liron updated ARIA-334:
---------------------------
    Description: 
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 one, 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.

  was:
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: aria.OperationConfigurationParameter

data_types:
  aria.OperationConfigurationParameter:
    derived_from: tosca.datatypes.Root
    properties:
      name:
        type: string
      value:
        type: 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 one, 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.


> 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 one, 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)

Mime
View raw message