Hi devs,
We are seeing more use of predicates and specs in blueprints. These are
powerful features and not too hard to express in blueprints using the
`$brooklyn:object` and `$brooklyn:entitySpec` DSL constructs, but I'm
thinking it's worth what I think will be a fairly small level of effort to
make these nicer to work with.
Currently for predicates, e.g. in a DynamicGroup or DynamicMultiGroup, to
filter the entities to accept we write something like this:
entityFilter:
$brooklyn:object:
type: org.apache.brooklyn.core.entity.EntityPredicates
factoryMethod.name: attributeEqualTo
factoryMethod.args:
- grouping
- web-app-tier
And for entity specs, e.g. in DynamicCluster or DynamicMultiGroup, to
define the spec of what should be created we write something like:
dynamiccluster.memberspec:
$brooklyn:entitySpec:
type: org.apache.brooklyn.entity.group.BasicGroup
brooklyn.config:
...
brooklyn.policies:
- ...
With the bean support and type coercion we have, it would not be too hard
to allow a simpler YAML without the $brooklyn DSL.
For predicates we could define a default deserialization to be used,
effectively a DSL for predicates. And for entity specs, where we know that
a spec is expected, if YAML is supplied we can support coercion from YAML
to specs directly. In both cases the current $brooklyn DSL syntax would
still be supported, but users would have the option to write simpler and
more readable YAML. I propose something like:
entityFilter:
sensor: grouping
equals: web-app-tier
and
dynamiccluster.memberspec:
type: org.apache.brooklyn.entity.group.BasicGroup
brooklyn.config:
...
brooklyn.policies:
- ...
For predicates we can easily add things like config and tags, and location
config and tags, and regex, not, any, all, {less,greater}-than{,-or-equal).
I think this would make it much more natural to read and write blueprints
that make use of the powerful filters and specs.
Thoughts?
Best
Alex
