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
