brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Kennedy <andrew.kenn...@cloudsoftcorp.com>
Subject Re: [PROPOSAL] YAML dsl enhancements
Date Tue, 29 Nov 2016 15:07:44 GMT
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 <
svetoslav.neykov@cloudsoftcorp.com> 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 <
> thomas.bouron@cloudsoftcorp.com> 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 <aled.sage@gmail.com> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message