Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 1A03A200CD5 for ; Sun, 30 Jul 2017 17:37:07 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 18310164320; Sun, 30 Jul 2017 15:37:07 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 36A2616431E for ; Sun, 30 Jul 2017 17:37:06 +0200 (CEST) Received: (qmail 94475 invoked by uid 500); 30 Jul 2017 15:37:05 -0000 Mailing-List: contact issues-help@ariatosca.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ariatosca.incubator.apache.org Delivered-To: mailing list issues@ariatosca.incubator.apache.org Received: (qmail 94459 invoked by uid 99); 30 Jul 2017 15:37:05 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 30 Jul 2017 15:37:05 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 017971A0653 for ; Sun, 30 Jul 2017 15:37:05 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -100.002 X-Spam-Level: X-Spam-Status: No, score=-100.002 tagged_above=-999 required=6.31 tests=[RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id EAZnKtIBuAML for ; Sun, 30 Jul 2017 15:37:03 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 009D15F2EC for ; Sun, 30 Jul 2017 15:37:03 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 77D24E00A9 for ; Sun, 30 Jul 2017 15:37:02 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 939642464A for ; Sun, 30 Jul 2017 15:37:01 +0000 (UTC) Date: Sun, 30 Jul 2017 15:37:00 +0000 (UTC) From: "Avia Efrat (JIRA)" To: issues@ariatosca.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (ARIA-334) Policy for operation execution configuration MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Sun, 30 Jul 2017 15:37:07 -0000 [ https://issues.apache.org/jira/browse/ARIA-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avia Efrat 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 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. 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: 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 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)