I see Andrew's suggested syntax nicely complement the relations idea. Currently it can work only on members/children, but there's nothing stopping us from extending it to relations. What I immediately think of is the axis in xpath. The default being children, but it can be replaced for any of the relations an entity takes part in. For example: //cluster/member:*/ssh-machine:*
Today we can implemented with support for "member", "child", "machine" hardcoded relations and replace the implementation with proper relations when we support them As for the indexing operator - don't have a strong opinion about it. If there are real-world cases where it can simplify blueprints then let's go for it (would like to see examples first). Just want to warn that it might need an unexpectedly big re-work of the DSL code so it can be supported: * The current evaluator loop is synchronous and doesn't wait for the resolvability of a value before it applies the next function call on the result. We'd need to make it lazy so it applies the rest of the calls only once it's able to resolve intermediate values. * We would need to wrap every returned value in a DslComponent-kind of wrapper so we can chain function calls (or in our case indexing operators) Svet. > On 30.11.2016 г., at 4:21, Alex Heneveld <[email protected]> > wrote: > > 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 >>
