brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Downer <rich...@apache.org>
Subject Re: VanillaSoftwareProcess and StaticSensor
Date Tue, 29 Sep 2015 10:03:06 GMT
Fantastic! Worked first time :-)

Thanks Aled

On 29 September 2015 at 10:45, Aled Sage <aled.sage@gmail.com> wrote:
> Hi Richard,
>
> To do this from YAML, you can use a "transformer" enricher. Here's a simple
> test I wrote, which you can adapt to your use-case:
>
>    services:
>    - type: org.apache.brooklyn.core.test.entity.TestEntity
>       id: childid
>       brooklyn.config:
>         jenkins.port: 1234
>       brooklyn.initializers:
>       - type: org.apache.brooklyn.core.sensor.StaticSensor
>         brooklyn.config:
>           name: host.name
>           static.value: myhostname
>       brooklyn.enrichers:
>       - enricherType: org.apache.brooklyn.enricher.stock.Transformer
>         brooklyn.config:
>           enricher.producer: $brooklyn:component("this" ,"")
>           enricher.sourceSensor: $brooklyn:sensor("host.name")
>           enricher.targetSensor: $brooklyn:sensor("main.uri")
>           enricher.targetValue: $brooklyn:formatString("http://%s:%s/",
>    $brooklyn:component("childid").attributeWhenReady("host.name"),
>    $brooklyn:component("childid").config("jenkins.port"))
>
> The transformer executes every time the source sensor is changed (in this
> case "host.name"). In this case, the "jenkins.port" is already set so it can
> resolve the value immediately.
>
> If jenkins.port was not available, the formatString would not yet be
> resolvable. It would retry next time "host.name" changed.
>
> Aled
>
> p.s. for your example, clearly you wouldn't have the StaticSensor for
> "host.name" - you'd rely on that being set automatically when the machine
> was obtained.
>
>
>
> On 29/09/2015 07:43, Richard Downer wrote:
>>
>> Hi Svet,
>>
>> On 29 September 2015 at 07:38, Svetoslav Neykov
>> <svetoslav.neykov@cloudsoftcorp.com> wrote:
>>>
>>> Attributes resolve values at set time, whereas config keys resolve at get
>>> time - can't have a future as the value of an attribute. I would approach
>>> this with some kind of transformer which monitors the dependent values and
>>> updates the target sensor. No out of the box solution to be used in YAML
>>> though.
>>
>> You've guessed what I was trying to do - express this as a pure-YAML
>> blueprint. Oh well! Something for the feature request list.
>>
>> Thanks for your response.
>>
>> Richard.
>
>

Mime
View raw message