Hi Devs, I've implemented this in https://github.com/apache/brooklyn-server/pull/1326 . For documentation, see:
https://github.com/apache/brooklyn-docs/pull/358/files This should make working with dynamic groups and multigroups much nicer! Best Alex On Fri, 17 Jun 2022 at 14:52, Alex Heneveld <a...@cloudsoft.io> wrote: > 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 > >
