brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aled Sage <>
Subject [PROPOSAL] YAML dsl enhancements
Date Tue, 08 Nov 2016 17:51:27 GMT
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:


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.

    - 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"
         target: target-app
             type: org.apache.brooklyn.test.framework.TestHttpCall
               applyAssertionTo: status
                 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:


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?



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