You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Richard Downer <ri...@apache.org> on 2015/09/28 23:24:32 UTC
VanillaSoftwareProcess and StaticSensor
Hi all,
I have a VanillaSoftwareProcess which is installing and running a web
app (Jenkins, to be exact). I'd like to add a sensor which shows the
URL of the webapp with the correct hostname and configured port
number, so I add this to the blueprint:
brooklyn.initializers:
- type: org.apache.brooklyn.core.sensor.StaticSensor
brooklyn.config:
name: jenkins.url
static.value: $brooklyn:formatString("http://%s:%s/",
attributeWhenReady("host.name"), config("jenkins.port"))
When I try this, the sensor is never populated. I can see it with a
blank value if I toggle the "show all sensors" icon.
If I remove the attributeWhen Ready part - so the format string is
only referring to the config - then the sensor is populated.
What's going on? Should I be able to use attributeWhenReady() with
StaticSensor and VanillaSoftwareProcess?
Thanks all,
Richard.
Re: VanillaSoftwareProcess and StaticSensor
Posted by Martin Harris <ma...@cloudsoftcorp.com>.
FYI, Robert (@robertgmoss) and I have been working on a reducing enricher
for a similar use case. In the case of the reducer enricher, the
transformer executes when *any* of the source sensors change. WIP is here[1]
Cheers
[1]:
https://github.com/apache/incubator-brooklyn/compare/master...nakomis:reducer-enricher
On 29 September 2015 at 11:03, Richard Downer <ri...@apache.org> wrote:
> Fantastic! Worked first time :-)
>
> Thanks Aled
>
> On 29 September 2015 at 10:45, Aled Sage <al...@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
> >> <sv...@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.
> >
> >
>
--
Martin Harris
Lead Software Engineer
Cloudsoft Corporation Ltd
www.cloudsoftcorp.com
Mobile: +44 (0)7989 047-855
--
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.
Re: VanillaSoftwareProcess and StaticSensor
Posted by Richard Downer <ri...@apache.org>.
Fantastic! Worked first time :-)
Thanks Aled
On 29 September 2015 at 10:45, Aled Sage <al...@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
>> <sv...@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.
>
>
Re: VanillaSoftwareProcess and StaticSensor
Posted by Aled Sage <al...@gmail.com>.
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
> <sv...@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.
Re: VanillaSoftwareProcess and StaticSensor
Posted by Richard Downer <ri...@apache.org>.
Hi Svet,
On 29 September 2015 at 07:38, Svetoslav Neykov
<sv...@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.
Re: VanillaSoftwareProcess and StaticSensor
Posted by Svetoslav Neykov <sv...@cloudsoftcorp.com>.
Richard,
StatisSensor tries to resolve the value at the time of attaching to the entity, which is not yet started and doesn't have the attribute set.
Instead of setting the value it logs to debug log with a note of the failure (https://github.com/apache/incubator-brooklyn/blob/master/core/src/main/java/org/apache/brooklyn/core/sensor/StaticSensor.java#L69 <https://github.com/apache/incubator-brooklyn/blob/master/core/src/main/java/org/apache/brooklyn/core/sensor/StaticSensor.java#L69>)
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.
Svet.
> On 29.09.2015 г., at 0:24, Richard Downer <ri...@apache.org> wrote:
>
> Hi all,
>
> I have a VanillaSoftwareProcess which is installing and running a web
> app (Jenkins, to be exact). I'd like to add a sensor which shows the
> URL of the webapp with the correct hostname and configured port
> number, so I add this to the blueprint:
>
> brooklyn.initializers:
> - type: org.apache.brooklyn.core.sensor.StaticSensor
> brooklyn.config:
> name: jenkins.url
> static.value: $brooklyn:formatString("http://%s:%s/",
> attributeWhenReady("host.name"), config("jenkins.port"))
>
> When I try this, the sensor is never populated. I can see it with a
> blank value if I toggle the "show all sensors" icon.
>
> If I remove the attributeWhen Ready part - so the format string is
> only referring to the config - then the sensor is populated.
>
> What's going on? Should I be able to use attributeWhenReady() with
> StaticSensor and VanillaSoftwareProcess?
>
> Thanks all,
> Richard.
--
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.