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 <[email protected]> wrote: > Fantastic! Worked first time :-) > > Thanks Aled > > On 29 September 2015 at 10:45, Aled Sage <[email protected]> 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 > >> <[email protected]> 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.
