What about a more modest proposal allowing `[#]` in DSL, to take the #th
item in any list or set?
So you could say `entity("cluster").children()[0]` or
`entity("cluster").attributeWhenReady("members")[0]` to get a member.
(Continuing: it depends on semantics of `members` whether it guarantees a
list of items in join order, but probably it would, and so `[0]` would give
the first ... and optionally `[-1]` could be used to mean the _last_.)
Rather less modest (so longer term ... the above could be done in an
afternoon) and I think in the spirit of what Andrew's sketch, if different
in the detail, would be to make more of relations. My gut says that a
jsonpath/xpath for the management hierarchy (our current tree) is
incomplete: it seems more like we want a richer relationship model in the
runtime view, and then an ability to traverse different named relations in
our DSL. This would be my preference also for locations, instead of a
`locations` keyword in the DSL, a `relations("running_on_machine")` phrase
would find the MachineLocation, same for members, or reads_data_from, or
load_balanced_by, etc. Needs more thought, use cases and sketched
solutions but feels more promising than the other options for DSL
expressiveness.
Best
Alex
On 29 November 2016 at 15:07, Andrew Kennedy <
[email protected]> wrote:
> I agree with Svet here. I started thinking about what that sort of thing
> would look like, and came up with this:
>
> - https://gist.github.com/grkvlt/59579e13c47aa89ff3fe504c9cd90d24
>
> Basically this is XPath but modified slightly for Brooklyn entitiy trees.
> I'd be interested in any comments before I turn it into a proper proposal.
>
> Andrew.
>
> On Fri, 11 Nov 2016 at 13:48 Svetoslav Neykov <
> [email protected]> wrote:
>
> > Not convinced that this is a useful thing to have.
> > * With #417 merged you can now do
> > $brooklyn:entity("cluster").attributeWhenReady("first.member").
> > * To take any random member you can assign them all the same ID and do
> > $brooklyn:entity("cluster").child("same-id-for-all-members") which will
> get
> > you any one of them (well maybe need to add member(..) method).
> > * With clusters you don't really have any ordering on the members (other
> > than the first one) so what do the indexes mean in practice? Why would
> you
> > use .member(2)?
> >
> > What I'd really like to see is expanding the scope functionality to offer
> > xpath-like functionality.
> >
> > Svet.
> >
> >
> > > On 11.11.2016 г., at 15:39, Thomas Bouron <
> > [email protected]> wrote:
> > >
> > > I'll say +1 to push for the get child/member by index, it will become
> > handy
> > > in cluster testing.
> > > For example, instead of specifying the `firstMemberSpec` in my
> tests[1],
> > we
> > > will be able to get the first member directly which is a much cleaner
> > way.
> > >
> > > [1] https://github.com/brooklyncentral/brooklyn-riak-cluster/pull/1
> > >
> > > On Fri, 11 Nov 2016 at 11:58 Aled Sage <[email protected]> wrote:
> > >
> > >> Hi all,
> > >>
> > >> @tbouron and @googlielmo reviewed and approved the first PR [2], so
> I've
> > >> merged that now. Thomas also made use of it for his tests in
> > >> https://github.com/brooklyncentral/brooklyn-riak-cluster/pull/1.
> > >>
> > >> Any comments, or shall I push on with the second part of the proposal
> > >> ("Get child/member by index")?
> > >>
> > >> Aled
> > >>
> > >>
> > >> On 08/11/2016 17:51, Aled Sage wrote:
> > >>> Hi all,
> > >>>
> > >>> I'd like us to make a few enhancements to the YAML DSL support. These
> > >>> are mostly motivated by trying to write some more complicated YAML
> > >>> test case examples.
> > >>>
> > >>> _*$brooklyn:entity() to support nested DSLs*_
> > >>> See [1], and the PR at [2].
> > >>>
> > >>> For example, being able to write:
> > >>>
> > >>> $brooklyn:entity(config("targetId")).attributeWhenReady("main.uri")
> > >>>
> > >>> This looks up the entity with the id specified in the targetId
> config,
> > >>> and then retrieves the main.uri sensor value from that entity.
> > >>>
> > >>> Currently, $brooklyn:entity() takes a string for the id of an entity
> > >>> to be looked up. However, in more dynamic situations the entity's id
> > >>> is only available on-the-fly as a sensor value (or a sensor value
> that
> > >>> is set to the entity itself).
> > >>>
> > >>> In the example below, the "loop-test" will go through the members of
> > >>> the Riak cluster, and will run the test-http against each. That test
> > >>> entity will then lookup the main.uri from that riak cluster member.
> > >>>
> > >>> services:
> > >>> - type: org.apache.brooklyn.entity.nosql.riak.RiakCluster
> > >>> id: target-app
> > >>> ...
> > >>> - type:
> > >>> org.apache.brooklyn.test.framework.LoopOverGroupMembersTestCase
> > >>> name: "Value replicated on all Riak nodes"
> > >>> brooklyn.config:
> > >>> target: target-app
> > >>> testSpec:
> > >>> $brooklyn:entitySpec:
> > >>> type: org.apache.brooklyn.test.framework.TestHttpCall
> > >>> brooklyn.config:
> > >>> url:
> > >>> $brooklyn:entity(config("targetId")).attributeWhenReady("main.uri")
> > >>> applyAssertionTo: status
> > >>> assert:
> > >>> equals: 200
> > >>>
> > >>> We'd also support retrieving a $brooklyn:entity() from sensor that
> > >>> points at the actual entity (rather than at the entity's id).
> > >>>
> > >>> _*Get child/member by index*_
> > >>> Currently, the $brooklyn:entity() and its variants takes an entity's
> > >>> id. It would be useful to be able to retrieve entities in other ways,
> > >>> without knowing their ids (particularly when those entities are
> nested
> > >>> inside a blueprint that someone else wrote).
> > >>>
> > >>> For example, we could retrieve the main.uri of the first and second
> > >>> members of a cluster by doing:
> > >>>
> > >>>
> > $brooklyn:entity("riak-cluster").member(0).
> attributeWhenReady("main.uri")
> > >>>
> > $brooklyn:entity("riak-cluster").member(1).
> attributeWhenReady("main.uri")
> > >>>
> > >>> We could similarly retrieve a child by index.
> > >>>
> > >>> This would be very useful for tests that write data using the first
> > >>> member, and then read the data using the second member of the
> cluster.
> > >>>
> > >>> _*Other enhancements?*_
> > >>> I suggest that we make improvements incrementally, starting with
> these.
> > >>>
> > >>> However, does anyone have any other enhancements that they'd really
> > >>> like to see?
> > >>>
> > >>> Aled
> > >>>
> > >>> [1] https://issues.apache.org/jira/browse/BROOKLYN-381
> > >>> [2] https://github.com/apache/brooklyn-server/pull/417
> > >>>
> > >>>
> > >>
> > >> --
> > >
> > > Thomas Bouron • Software Engineer @ Cloudsoft Corporation •
> > > http://www.cloudsoftcorp.com/
> > > Github: https://github.com/tbouron
> > > Twitter: https://twitter.com/eltibouron
> >
> > --
>
> Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
>
