brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aled Sage <>
Subject [PROPOSAL] $brooklyn:attributeWhenReady semantics
Date Fri, 05 Aug 2016 16:07:05 GMT
Hi all,

Motivated by Andrew's recent PR [1] and Svet's suggestion, I'd like to 
propose a change to the semantics/arguments to 

_*Current Behaviour*_

_Simple example_
If you write in a YAML blueprint something like:

       myurl: $brooklyn:component("db").attributeWhenReady("datastore.url")

then when you attempt to get the config value for "myurl" it will block 
until the "datastore.url" sensor value is available on the entity with 
id "db".

_"Groovy truth" example_
The attributeWhenReady actually blocks until groovy truth is satisfied 
(boolean is true, collection is non-empty, string is non-empty, etc).

You can therefore write:


and it will block until the db entity's service.isUp sensor is true.

Unfortunately this means it's impossible to wait for a boolean attribute 
to be non-null (i.e. stop waiting when false or true).

_Java API Functionality_
Comparing the yaml DSL with what can be done in DependentConfiguration 
[2], there is a lot we can't do:

  * customize the "readiness" function (i.e. what sensor values mean
  * define "abort conditions" (e.g. stop waiting if the entity
    transitions to some other state)
  * specify a timeout
  * give a default value for if there is a timeout, or if the entity is
    removed while we're waiting.

_*Proposal: option 1*_

My favoured option is to make attributeWhenReady more configurable.

For example, we could support:

       launch.latch: $brooklyn:component("db").attributeWhenReady:
         sensor: "service.isUp"
         readiness: $brooklyn:predicates.equalTo("true")
         timeout: 10m

Maybe we'd support overloading of in-lining the args (relying on 
parameter order of [sensor, readiness, timeout]), such as:

    $brooklyn:predicates.equalTo("true"), 10m)

I think I'm ok with leaving the default as groovy-truth semantics, as 
long as we make the documentation clearer for that.

However, this proposal might well be hard to implement. It would likely 
require significant change to how we parse the $brooklyn expressions (if 
my recollection of this code is correct).

_*Proposal: option 2*_

An alternative suggested by Svet in a comment on [1]:

    Should we fix attributeWhenReady instead? It's confusing to have it
    wait indefinitely on false.
    Having another attribute, very similar to attributeWhenReady
    complicates things even further.

    Suggest renaming attributeWhenRedy to attributeWhenTruth and
    changing attributeWhenReady to wait on notNull && notEmpty.

That sounds like a good idea - it feels much more explicit, and is very 
simple to implement.

However, it would break backwards compatibility (e.g. for those using 

If we think the semantics are wrong, then we should definitely change it 
while we're still on version 0.x rather than ignoring it.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message