brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Svetoslav Neykov <svetoslav.ney...@cloudsoftcorp.com>
Subject Re: [PROPOSAL] YAML dsl enhancements
Date Fri, 11 Nov 2016 13:48:46 GMT
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


Mime
View raw message