You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by "Aled Sage (JIRA)" <ji...@apache.org> on 2017/04/27 14:07:04 UTC
[jira] [Updated] (BROOKLYN-494) CompositeEffector: pass different
parameters to each effector in chain
[ https://issues.apache.org/jira/browse/BROOKLYN-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aled Sage updated BROOKLYN-494:
-------------------------------
Description:
When using {{CompositeEffector}} in yaml, I'd like to pass different arguments to each effector being called in the {{CompositeEffector}}
It's possible to workaround this by declaring multiple very specific effectors with hard-coded URLs/commands, which are then chained together.
For example, I'd like to write something like:
{noformat}
location: localhost
services:
- type: org.apache.brooklyn.entity.machine.MachineEntity
brooklyn.initializers:
- type: org.apache.brooklyn.core.sensor.http.HttpRequestSensor
brooklyn.config:
name: service.isUp
uri:
$brooklyn:formatString:
- http://%s:8081/health
- $brooklyn:attributeWhenReady("host.name")
targetType: boolean
period: 1s
- type: org.apache.brooklyn.core.effector.http.HttpCommandEffector
brooklyn.config:
name: httpEffector
- type: org.apache.brooklyn.core.effector.ssh.SshCommandEffector
brooklyn.config:
name: execCommand
- type: org.apache.brooklyn.core.effector.CompositeEffector
brooklyn.config:
name: start
effectors:
- name: execCommand
args:
command: doSomething.sh
- name: httpEffector
args:
uri:
$brooklyn:formatString:
- http://%s:8081/initSomething
- $brooklyn:attributeWhenReady("host.name")
httpVerb: POST
httpPayload: someHttpBody
{noformat}
Note that a few more things go wrong if you try to use the blueprint above:
* The {{SshCommandEffector}} expects the command to be configured in the effector declaration, rather than passed as an effector argument.
* The {{HttpCommandEffector}} similarly expects the uri, httpVerb etc to be configured in the effector declaration, rather than passed as effector arguments.
* Setting {{service.isUp}} directly probably isn't the best way - we'd likely want to make use of the {{service.notUp.indicators}}
(Also note that {{MachineEntity}} actually already declares an {{execCommand}} effector, but let's ignore that as I'm exploring what is possible in pure-yaml blueprints.
Below is an example blueprint to show what is currently possible:
{noformat}
location: localhost
services:
- type: org.apache.brooklyn.entity.machine.MachineEntity
brooklyn.initializers:
- type: org.apache.brooklyn.core.effector.http.HttpCommandEffector
brooklyn.config:
name: httpEffector
uri:
$brooklyn:formatString:
- http://%s:8081/initSomething
- $brooklyn:attributeWhenReady("host.name")
httpVerb: POST
httpPayload: someHttpBody
- type: org.apache.brooklyn.core.effector.ssh.SshCommandEffector
brooklyn.config:
name: execCommand
command: echo myCommand
- type: org.apache.brooklyn.core.effector.CompositeEffector
brooklyn.config:
name: start
effectors:
- execCommand
- httpEffector
{noformat}
It is also already possible in {{CompositeEffector}} to declare parameters to be passed in by the caller. These are passed to all effectors called by the composite (however, for something like augmenting the {{start}} effector is desired then that isn't particularly helpful):
{noformat}
- type: org.apache.brooklyn.core.effector.CompositeEffector
brooklyn.config:
name: start
parameters:
command:
type: String
effectors:
- execCommand
- httpEffector
{noformat}
was:
When using {{CompositeEffector}} in yaml, I'd like to pass different arguments to each effector being called in the {{CompositeEffector}}
It's possible to workaround this by declaring multiple very specific effectors with hard-coded URLs/commands, which are then chained together.
For example, I'd like to write something like:
{noformat}
location: localhost
services:
- type: org.apache.brooklyn.entity.machine.MachineEntity
brooklyn.initializers:
- type: org.apache.brooklyn.core.sensor.http.HttpRequestSensor
brooklyn.config:
name: service.isUp
uri:
$brooklyn:formatString:
- http://%s:8081/health
- $brooklyn:attributeWhenReady("host.name")
targetType: boolean
period: 1s
- type: org.apache.brooklyn.core.effector.SetSensor
brooklyn.config:
name: setSensor
- type: org.apache.brooklyn.core.effector.http.HttpCommandEffector
brooklyn.config:
name: httpEffector
- type: org.apache.brooklyn.core.effector.ssh.SshCommandEffector
brooklyn.config:
name: execCommand
- type: org.apache.brooklyn.core.effector.CompositeEffector
brooklyn.config:
name: start
effectors:
- name: execCommand
args:
command: doSomething.sh
- name: httpEffector
args:
uri:
$brooklyn:formatString:
- http://%s:8081/initSomething
- $brooklyn:attributeWhenReady("host.name")
httpVerb: POST
httpPayload: someHttpBody
{noformat}
Note that a few more things go wrong if you try to use the blueprint above:
* The {{SshCommandEffector}} expects the command to be configured in the effector declaration, rather than passed as an effector argument.
* The {{HttpCommandEffector}} similarly expects the uri, httpVerb etc to be configured in the effector declaration, rather than passed as effector arguments.
* Setting {{service.isUp}} directly probably isn't the best way - we'd likely want to make use of the {{service.notUp.indicators}}
(Also note that {{MachineEntity}} actually already declares an {{execCommand}} effector, but let's ignore that as I'm exploring what is possible in pure-yaml blueprints.
Below is an example blueprint to show what is currently possible:
{noformat}
location: localhost
services:
- type: org.apache.brooklyn.entity.machine.MachineEntity
brooklyn.initializers:
- type: org.apache.brooklyn.core.effector.http.HttpCommandEffector
brooklyn.config:
name: httpEffector
uri:
$brooklyn:formatString:
- http://%s:8081/initSomething
- $brooklyn:attributeWhenReady("host.name")
httpVerb: POST
httpPayload: someHttpBody
- type: org.apache.brooklyn.core.effector.ssh.SshCommandEffector
brooklyn.config:
name: execCommand
command: echo myCommand
- type: org.apache.brooklyn.core.effector.CompositeEffector
brooklyn.config:
name: start
effectors:
- execCommand
- httpEffector
{noformat}
It is also already possible in {{CompositeEffector}} to declare parameters to be passed in by the caller. These are passed to all effectors called by the composite (however, for something like augmenting the {{start}} effector is desired then that isn't particularly helpful):
{noformat}
- type: org.apache.brooklyn.core.effector.CompositeEffector
brooklyn.config:
name: start
parameters:
command:
type: String
effectors:
- execCommand
- httpEffector
{noformat}
> CompositeEffector: pass different parameters to each effector in chain
> ----------------------------------------------------------------------
>
> Key: BROOKLYN-494
> URL: https://issues.apache.org/jira/browse/BROOKLYN-494
> Project: Brooklyn
> Issue Type: Improvement
> Reporter: Aled Sage
> Priority: Minor
>
> When using {{CompositeEffector}} in yaml, I'd like to pass different arguments to each effector being called in the {{CompositeEffector}}
> It's possible to workaround this by declaring multiple very specific effectors with hard-coded URLs/commands, which are then chained together.
> For example, I'd like to write something like:
> {noformat}
> location: localhost
>
> services:
> - type: org.apache.brooklyn.entity.machine.MachineEntity
> brooklyn.initializers:
> - type: org.apache.brooklyn.core.sensor.http.HttpRequestSensor
> brooklyn.config:
> name: service.isUp
> uri:
> $brooklyn:formatString:
> - http://%s:8081/health
> - $brooklyn:attributeWhenReady("host.name")
> targetType: boolean
> period: 1s
> - type: org.apache.brooklyn.core.effector.http.HttpCommandEffector
> brooklyn.config:
> name: httpEffector
> - type: org.apache.brooklyn.core.effector.ssh.SshCommandEffector
> brooklyn.config:
> name: execCommand
> - type: org.apache.brooklyn.core.effector.CompositeEffector
> brooklyn.config:
> name: start
> effectors:
> - name: execCommand
> args:
> command: doSomething.sh
> - name: httpEffector
> args:
> uri:
> $brooklyn:formatString:
> - http://%s:8081/initSomething
> - $brooklyn:attributeWhenReady("host.name")
> httpVerb: POST
> httpPayload: someHttpBody
> {noformat}
> Note that a few more things go wrong if you try to use the blueprint above:
> * The {{SshCommandEffector}} expects the command to be configured in the effector declaration, rather than passed as an effector argument.
> * The {{HttpCommandEffector}} similarly expects the uri, httpVerb etc to be configured in the effector declaration, rather than passed as effector arguments.
> * Setting {{service.isUp}} directly probably isn't the best way - we'd likely want to make use of the {{service.notUp.indicators}}
> (Also note that {{MachineEntity}} actually already declares an {{execCommand}} effector, but let's ignore that as I'm exploring what is possible in pure-yaml blueprints.
> Below is an example blueprint to show what is currently possible:
> {noformat}
> location: localhost
>
> services:
> - type: org.apache.brooklyn.entity.machine.MachineEntity
> brooklyn.initializers:
> - type: org.apache.brooklyn.core.effector.http.HttpCommandEffector
> brooklyn.config:
> name: httpEffector
> uri:
> $brooklyn:formatString:
> - http://%s:8081/initSomething
> - $brooklyn:attributeWhenReady("host.name")
> httpVerb: POST
> httpPayload: someHttpBody
> - type: org.apache.brooklyn.core.effector.ssh.SshCommandEffector
> brooklyn.config:
> name: execCommand
> command: echo myCommand
> - type: org.apache.brooklyn.core.effector.CompositeEffector
> brooklyn.config:
> name: start
> effectors:
> - execCommand
> - httpEffector
> {noformat}
> It is also already possible in {{CompositeEffector}} to declare parameters to be passed in by the caller. These are passed to all effectors called by the composite (however, for something like augmenting the {{start}} effector is desired then that isn't particularly helpful):
> {noformat}
> - type: org.apache.brooklyn.core.effector.CompositeEffector
> brooklyn.config:
> name: start
> parameters:
> command:
> type: String
> effectors:
> - execCommand
> - httpEffector
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)