Re: Proposal to simplify predicates and specs

[Geoff Macartney <ge...@gmail.com>]

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 <al...@cloudsoft.io> 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 <al...@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
> >
> >
>