Hi Alex, Know I'm late replying but just to say these look like very useful additions to the blueprint syntax, great stuff!
Geoff On Mon, 27 Jun 2022 at 13:09, Alex Heneveld <[email protected]> wrote: > 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 <[email protected]> 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 > > > > >
