You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Aled Sage <al...@gmail.com> on 2016/11/08 17:51:27 UTC
[PROPOSAL] YAML dsl enhancements
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
Re: [PROPOSAL] YAML dsl enhancements
Posted by Svetoslav Neykov <sv...@cloudsoftcorp.com>.
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 <al...@cloudsoftcorp.com> 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 <
> andrew.kennedy@cloudsoftcorp.com> 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 <
>> 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 <al...@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
>>
Re: [PROPOSAL] YAML dsl enhancements
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
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 <
andrew.kennedy@cloudsoftcorp.com> 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 <
> 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 <al...@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
>
Re: [PROPOSAL] YAML dsl enhancements
Posted by Andrew Kennedy <an...@cloudsoftcorp.com>.
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 <al...@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
Re: [PROPOSAL] YAML dsl enhancements
Posted by Svetoslav Neykov <sv...@cloudsoftcorp.com>.
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 <th...@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 <al...@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
Re: [PROPOSAL] YAML dsl enhancements
Posted by Thomas Bouron <th...@cloudsoftcorp.com>.
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 <al...@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
Re: [PROPOSAL] YAML dsl enhancements
Posted by Aled Sage <al...@gmail.com>.
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
>
>