[jira] [Comment Edited] (BROOKLYN-454) Can't chain `$brooklyn:config("entity")` with subsequent DSL expressions

2017-03-22 Thread Mike Zaccardo (JIRA) 

[ 
https://issues.apache.org/jira/browse/BROOKLYN-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937486#comment-15937486
 ] 

Mike Zaccardo edited comment on BROOKLYN-454 at 3/23/17 12:59 AM:
--

$brooklyn:entity(config("entity")).attributeWhenReady("sensor")

also works with:

$brooklyn:entity($brooklyn:attributeWhenReady("sensor.that.returns.an.entity")).attributeWhenReady("sensor")


was (Author: mike.zaccardo):
$brooklyn:entity(config("entity")).attributeWhenReady("sensor")

also works with:

  
  
$brooklyn:entity($brooklyn:attributeWhenReady("sensor.that.returns.an.entity")).attributeWhenReady("sensor")

> Can't chain `$brooklyn:config("entity")` with subsequent DSL expressions
> 
>
> Key: BROOKLYN-454
> URL: https://issues.apache.org/jira/browse/BROOKLYN-454
> Project: Brooklyn
>  Issue Type: Bug
> Environment: Brooklyn 0.11.0-SNAPSHOT
>Reporter: Duncan Godwin
>
> Brooklyn seems to evaluate {{$brooklyn:config}} incorrectly in a latch. The 
> following used to work in Apache Brooklyn 0.10.0 but no longer does:
> {code}
> location: localhost
> services:
> - type: org.apache.brooklyn.entity.stock.BasicApplication
>   name: my-parent
>   brooklyn.config:
> root.entity: $brooklyn:self()
>   brooklyn.children:
>   - type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
> name: my-child
> brooklyn.config:
>   launch.command: echo Launching
>   checkRunning.command: echo CheckRunning
>   stop.command: echo Stopping
>   launch.latch: 
> $brooklyn:config("root.entity").attributeWhenReady("sensorInParent")
> {code}
> The following does work:
> {code}
> location: localhost
> services:
> - type: org.apache.brooklyn.entity.stock.BasicApplication
>   name: my-parent
>   brooklyn.config:
> root.entity: $brooklyn:self()
>   brooklyn.children:
>   - type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
> name: my-child
> brooklyn.initializers:
> - type: org.apache.brooklyn.core.sensor.StaticSensor
>   brooklyn.config:
> name: root.entity
> targetType: org.apache.brooklyn.api.entity.Entity
> static.value: $brooklyn:config("root.entity")
> brooklyn.config:
>   launch.command: echo Launching
>   checkRunning.command: echo CheckRunning
>   stop.command: echo Stopping
>   launch.latch: 
> $brooklyn:attributeWhenReady("root.entity").attributeWhenReady("sensorInParent")
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (BROOKLYN-454) Can't chain `$brooklyn:config("entity")` with subsequent DSL expressions

2017-03-22 Thread Mike Zaccardo (JIRA) 

[ 
https://issues.apache.org/jira/browse/BROOKLYN-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937486#comment-15937486
 ] 

Mike Zaccardo edited comment on BROOKLYN-454 at 3/23/17 12:58 AM:
--

```$brooklyn:entity(config("entity")).attributeWhenReady("sensor")``` 

also works with:

```
$brooklyn:entity($brooklyn:attributeWhenReady("sensor.that.returns.an.entity")).attributeWhenReady("sensor")
```


was (Author: mike.zaccardo):
`$brooklyn:entity(config("entity")).attributeWhenReady("sensor")` also works 
with:

`$brooklyn:entity($brooklyn:attributeWhenReady("sensor.that.returns.an.entity")).attributeWhenReady("sensor")`

> Can't chain `$brooklyn:config("entity")` with subsequent DSL expressions
> 
>
> Key: BROOKLYN-454
> URL: https://issues.apache.org/jira/browse/BROOKLYN-454
> Project: Brooklyn
>  Issue Type: Bug
> Environment: Brooklyn 0.11.0-SNAPSHOT
>Reporter: Duncan Godwin
>
> Brooklyn seems to evaluate {{$brooklyn:config}} incorrectly in a latch. The 
> following used to work in Apache Brooklyn 0.10.0 but no longer does:
> {code}
> location: localhost
> services:
> - type: org.apache.brooklyn.entity.stock.BasicApplication
>   name: my-parent
>   brooklyn.config:
> root.entity: $brooklyn:self()
>   brooklyn.children:
>   - type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
> name: my-child
> brooklyn.config:
>   launch.command: echo Launching
>   checkRunning.command: echo CheckRunning
>   stop.command: echo Stopping
>   launch.latch: 
> $brooklyn:config("root.entity").attributeWhenReady("sensorInParent")
> {code}
> The following does work:
> {code}
> location: localhost
> services:
> - type: org.apache.brooklyn.entity.stock.BasicApplication
>   name: my-parent
>   brooklyn.config:
> root.entity: $brooklyn:self()
>   brooklyn.children:
>   - type: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess
> name: my-child
> brooklyn.initializers:
> - type: org.apache.brooklyn.core.sensor.StaticSensor
>   brooklyn.config:
> name: root.entity
> targetType: org.apache.brooklyn.api.entity.Entity
> static.value: $brooklyn:config("root.entity")
> brooklyn.config:
>   launch.command: echo Launching
>   checkRunning.command: echo CheckRunning
>   stop.command: echo Stopping
>   launch.latch: 
> $brooklyn:attributeWhenReady("root.entity").attributeWhenReady("sensorInParent")
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Trouble with YAML Transformer

2017-03-22 Thread Mike Zaccardo 
>From the DSL spec [
https://docs.cloudsoft.io/blueprints/syntax-yaml-reference.html#dsl-commands
]:

* $brooklyn:sensor("sensor.name") returns the given sensor on the current
entity if found, or an untyped (Object) sensor;

* $brooklyn:sensor("com.acme.brooklyn.ContainingEntityClass", "sensor.name")
returns the strongly typed sensor defined in the given class

Based on that, it seemed to me that the first, single-argument value would
actually return the value of the sensor (the "object"), not the sensor
construct itself (the "class").  However, I tried updating your code and
ended up with an empty-valued sensor.

  brooklyn.enrichers:
- type: org.apache.brooklyn.enricher.stock.Transformer
  brooklyn.config:
enricher.sourceSensor: $brooklyn:sensor("cluster.first.entity")
enricher.targetSensor: $brooklyn:sensor("cluster_first_host")
enricher.targetValue:
  $brooklyn:formatString:
  - "%s"
  -
$brooklyn:sensor("cluster.first.entity").attributeWhenReady("host.name")

I'd like to kick the question to the rest of the community -- why does that
^ end up with an empty value? It should default to searching the current
entity, which is a `DynamicCluster`, which has a `cluster.first.entity`.

-Mike

On Wed, Mar 22, 2017 at 12:52 PM Graham Ashby <graham.as...@ca.ibm.com>
wrote:

OK, Stupid mistake.
So, when I changed it to colon, I got the error:
2017-03-22 15:41:43,612 WARN  o.a.b.c.b.s.d.BrooklynDslInterpreter
[brooklyn-jetty-server-8081-qtp434786215-42]: Error evaluating node
(rethrowing) '$brooklyn:sensor("org.apache.brooklyn.api.entity.Entity",
"cluster.first.entity").attributeWhenReady("host.name")':
org.apache.brooklyn.util.exceptions.PropagatedRuntimeException: Sensor
cluster.first.entity not found on class
org.apache.brooklyn.api.entity.Entity

So I changed the Cast:

  enricher.targetValue:
$brooklyn:sensor("org.apache.brooklyn.entity.group.AbstractGroup",
"cluster.first.entity").attributeWhenReady("host.name")

Now I get:

2017-03-22 15:43:50,909 WARN  o.a.b.c.b.s.d.BrooklynDslInterpreter
[brooklyn-jetty-server-8081-qtp434786215-2217]: Error evaluating node
(rethrowing)
'$brooklyn:sensor("org.apache.brooklyn.entity.group.AbstractGroup",
"cluster.first.entity").attributeWhenReady("host.name")':
java.lang.IllegalArgumentException: Not permitted to invoke function on
'class org.apache.brooklyn.core.sensor.BasicAttributeSensor' (outside
allowed package scope)

Thanks
G



From:   Mike Zaccardo <mike.zacca...@cloudsoftcorp.com>
To: Brooklyn dev <dev@brooklyn.apache.org>
Date:   03/22/2017 03:30 PM
Subject:Re: Trouble with YAML Transformer



Hi Graham,

In your `enricher.targetValue` -- `$brooklyn.sensor` should be
`$brooklyn:sensor`
(the dot replaced by a colon).

If that does not solve it, try providing the `enricher.targetValue` with
string, like so:

brooklyn.enrichers:
  - type: org.apache.brooklyn.enricher.stock.Transformer
brooklyn.config:
  enricher.sourceSensor: $brooklyn:sensor("cluster.first.entity")
  enricher.targetSensor: $brooklyn:sensor("cluster_first_host")
  enricher.targetValue:
$brooklyn:formatString:
- "%s"
-
$brooklyn:sensor("org.apache.brooklyn.api.entity.Entity",
"cluster.first.entity").attributeWhenReady("
host.name")

I hope this helps.

Cheers,
Mike

On Wed, Mar 22, 2017 at 12:10 PM Graham Ashby <graham.as...@ca.ibm.com>
wrote:

What I want is an attribute that I can include in a template.
I'm trying to get the host.name of the first entity in the cluster, so
what I've got is:

brooklyn.enrichers:
  - type: org.apache.brooklyn.enricher.stock.Transformer
brooklyn.config:
  enricher.sourceSensor: $brooklyn:sensor("cluster.first.entity")
  enricher.targetSensor: $brooklyn:sensor("cluster_first_host")
  enricher.targetValue:
$brooklyn.sensor("org.apache.brooklyn.api.entity.Entity",
"cluster.first.entity").attributeWhenReady("host.name")

But I get the literal value
"$brooklyn.sensor("org.apache.brooklyn.api.entity.Entity",
"cluster.first.entity").attributeWhenReady("host.name")"

So, what am I doing wrong?

Thanks
Graham

--

Mike Zaccardo

Senior Software Engineer

Skype: mike.cloudsoft

Twitter: @ItsMeMikeZ <https://twitter.com/ItsMeMikeZ> LinkedIn:
linkedin.com/in/mike-zaccardo
<https://www.linkedin.com/in/mike-zaccardo-aa3ab812>

[image: Cloudsoft Logo.jpg] <https://cloudsoft.io/>

Stay up to date with everything Cloudsoft:

[image: Twitter_Logo_White_On_Blue.png] <https://twitte

Re: Trouble with YAML Transformer

2017-03-22 Thread Mike Zaccardo 
Sorry Graham, once you replace the dot with the colon it will spit out an
error since `org.apache.brooklyn.api.entity.Entity` does not contain a
`cluster.first.entity` sensor. I'm testing it out myself looking for a
solution for you.

-Mike

On Wed, Mar 22, 2017 at 12:23 PM Mike Zaccardo <
mike.zacca...@cloudsoftcorp.com> wrote:

> Hi Graham,
>
> In your `enricher.targetValue` -- `$brooklyn.sensor` should be 
> `$brooklyn:sensor`
> (the dot replaced by a colon).
>
> If that does not solve it, try providing the `enricher.targetValue` with
> string, like so:
>
> brooklyn.enrichers:
>   - type: org.apache.brooklyn.enricher.stock.Transformer
> brooklyn.config:
>   enricher.sourceSensor: $brooklyn:sensor("cluster.first.entity")
>   enricher.targetSensor: $brooklyn:sensor("cluster_first_host")
>   enricher.targetValue:
> $brooklyn:formatString:
> - "%s"
> -
> $brooklyn:sensor("org.apache.brooklyn.api.entity.Entity", 
> "cluster.first.entity").attributeWhenReady("
> host.name")
>
> I hope this helps.
>
> Cheers,
> Mike
>
> On Wed, Mar 22, 2017 at 12:10 PM Graham Ashby <graham.as...@ca.ibm.com>
> wrote:
>
> What I want is an attribute that I can include in a template.
> I'm trying to get the host.name of the first entity in the cluster, so
> what I've got is:
>
> brooklyn.enrichers:
>   - type: org.apache.brooklyn.enricher.stock.Transformer
> brooklyn.config:
>   enricher.sourceSensor: $brooklyn:sensor("cluster.first.entity")
>   enricher.targetSensor: $brooklyn:sensor("cluster_first_host")
>   enricher.targetValue:
> $brooklyn.sensor("org.apache.brooklyn.api.entity.Entity",
> "cluster.first.entity").attributeWhenReady("host.name")
>
> But I get the literal value
> "$brooklyn.sensor("org.apache.brooklyn.api.entity.Entity",
> "cluster.first.entity").attributeWhenReady("host.name")"
>
> So, what am I doing wrong?
>
> Thanks
> Graham
>
> --
>
> Mike Zaccardo
>
> Senior Software Engineer
>
> Skype: mike.cloudsoft
>
> Twitter: @ItsMeMikeZ <https://twitter.com/ItsMeMikeZ> LinkedIn:
> linkedin.com/in/mike-zaccardo
> <https://www.linkedin.com/in/mike-zaccardo-aa3ab812>
>
> [image: Cloudsoft Logo.jpg] <https://cloudsoft.io/>
>
> Stay up to date with everything Cloudsoft:
>
> [image: Twitter_Logo_White_On_Blue.png] <https://twitter.com/cloudsoft> 
> [image:
> YouTube-social-icon_red_48px.png]
> <https://www.youtube.com/channel/UCpbLhvXrYWz8B_osUX6rn0Q>
>
> --

Mike Zaccardo

Senior Software Engineer

Skype: mike.cloudsoft

Twitter: @ItsMeMikeZ <https://twitter.com/ItsMeMikeZ> LinkedIn:
linkedin.com/in/mike-zaccardo
<https://www.linkedin.com/in/mike-zaccardo-aa3ab812>

[image: Cloudsoft Logo.jpg] <https://cloudsoft.io/>

Stay up to date with everything Cloudsoft:

[image: Twitter_Logo_White_On_Blue.png] <https://twitter.com/cloudsoft> [image:
YouTube-social-icon_red_48px.png]
<https://www.youtube.com/channel/UCpbLhvXrYWz8B_osUX6rn0Q>

Re: Trouble with YAML Transformer

2017-03-22 Thread Mike Zaccardo 
Hi Graham,

In your `enricher.targetValue` -- `$brooklyn.sensor` should be
`$brooklyn:sensor`
(the dot replaced by a colon).

If that does not solve it, try providing the `enricher.targetValue` with
string, like so:

brooklyn.enrichers:
  - type: org.apache.brooklyn.enricher.stock.Transformer
brooklyn.config:
  enricher.sourceSensor: $brooklyn:sensor("cluster.first.entity")
  enricher.targetSensor: $brooklyn:sensor("cluster_first_host")
  enricher.targetValue:
$brooklyn:formatString:
- "%s"
-
$brooklyn:sensor("org.apache.brooklyn.api.entity.Entity",
"cluster.first.entity").attributeWhenReady("
host.name")

I hope this helps.

Cheers,
Mike

On Wed, Mar 22, 2017 at 12:10 PM Graham Ashby <graham.as...@ca.ibm.com>
wrote:

What I want is an attribute that I can include in a template.
I'm trying to get the host.name of the first entity in the cluster, so
what I've got is:

brooklyn.enrichers:
  - type: org.apache.brooklyn.enricher.stock.Transformer
brooklyn.config:
  enricher.sourceSensor: $brooklyn:sensor("cluster.first.entity")
  enricher.targetSensor: $brooklyn:sensor("cluster_first_host")
  enricher.targetValue:
$brooklyn.sensor("org.apache.brooklyn.api.entity.Entity",
"cluster.first.entity").attributeWhenReady("host.name")

But I get the literal value
"$brooklyn.sensor("org.apache.brooklyn.api.entity.Entity",
"cluster.first.entity").attributeWhenReady("host.name")"

So, what am I doing wrong?

Thanks
Graham

-- 

Mike Zaccardo

Senior Software Engineer

Skype: mike.cloudsoft

Twitter: @ItsMeMikeZ <https://twitter.com/ItsMeMikeZ> LinkedIn:
linkedin.com/in/mike-zaccardo
<https://www.linkedin.com/in/mike-zaccardo-aa3ab812>

[image: Cloudsoft Logo.jpg] <https://cloudsoft.io/>

Stay up to date with everything Cloudsoft:

[image: Twitter_Logo_White_On_Blue.png] <https://twitter.com/cloudsoft> [image:
YouTube-social-icon_red_48px.png]
<https://www.youtube.com/channel/UCpbLhvXrYWz8B_osUX6rn0Q>

[jira] [Updated] (BROOKLYN-439) Existing `userMetadata` cannot be used with WinRM deployments on certain clouds

2017-02-15 Thread Mike Zaccardo (JIRA) 

 [ 
https://issues.apache.org/jira/browse/BROOKLYN-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Zaccardo updated BROOKLYN-439:
---
Environment: 
AWS
Vcloud Director
Description: 
*Applies to AWS and Vcloud Director based clouds*

When deploying a WinRM-based blueprint, the `userMetadata` of the deployment 
location's configuration must be empty. See: 
http://docs.cloudsoft.io/blueprints/base-blueprints/winrm/index.html#user-metadata-service-requirement

This prevents the user from deploying with any other potentially useful 
`userMetadata` values, like their email or a "keep" tag. It will also cause the 
WinRM deployment to fail if the user does not realize that s/he has existing 
`userMetadata` in place, and there is no relevant error message to make this 
clear.

Ideally the existing `userMetadata` could be merged with the necessary WinRM 
script so the user does not have to abandon their desired `userMetadata`.

The relevant code is here: 
https://github.com/apache/brooklyn-server/blob/master/locations/jclouds/src/main/java/org/apache/brooklyn/location/jclouds/JcloudsLocation.java#L1470

  was:
When deploying a WinRM-based blueprint, the `userMetadata` of the deployment 
location's configuration must be empty. See: 
http://docs.cloudsoft.io/blueprints/base-blueprints/winrm/index.html#user-metadata-service-requirement

This prevents the user from deploying with any other potentially useful 
`userMetadata` values, like their email or a "keep" tag. It will also cause the 
WinRM deployment to fail if the user does not realize that s/he has existing 
`userMetadata` in place, and there is no relevant error message to make this 
clear.

Ideally the existing `userMetadata` could be merged with the necessary WinRM 
script so the user does not have to abandon their desired `userMetadata`.

The relevant code is here: 
https://github.com/apache/brooklyn-server/blob/master/locations/jclouds/src/main/java/org/apache/brooklyn/location/jclouds/JcloudsLocation.java#L1470

Summary: Existing `userMetadata` cannot be used with WinRM deployments 
on certain clouds  (was: Existing `userMetadata` cannot be used with WinRM 
deployments)

> Existing `userMetadata` cannot be used with WinRM deployments on certain 
> clouds
> ---
>
> Key: BROOKLYN-439
> URL: https://issues.apache.org/jira/browse/BROOKLYN-439
> Project: Brooklyn
>  Issue Type: Improvement
>Affects Versions: 0.11.0
> Environment: AWS
> Vcloud Director
>Reporter: Mike Zaccardo
>Priority: Minor
>  Labels: windows
>
> *Applies to AWS and Vcloud Director based clouds*
> When deploying a WinRM-based blueprint, the `userMetadata` of the deployment 
> location's configuration must be empty. See: 
> http://docs.cloudsoft.io/blueprints/base-blueprints/winrm/index.html#user-metadata-service-requirement
> This prevents the user from deploying with any other potentially useful 
> `userMetadata` values, like their email or a "keep" tag. It will also cause 
> the WinRM deployment to fail if the user does not realize that s/he has 
> existing `userMetadata` in place, and there is no relevant error message to 
> make this clear.
> Ideally the existing `userMetadata` could be merged with the necessary WinRM 
> script so the user does not have to abandon their desired `userMetadata`.
> The relevant code is here: 
> https://github.com/apache/brooklyn-server/blob/master/locations/jclouds/src/main/java/org/apache/brooklyn/location/jclouds/JcloudsLocation.java#L1470



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (BROOKLYN-439) Existing `userMetadata` cannot be used with WinRM deployments

2017-02-15 Thread Mike Zaccardo (JIRA) 
Mike Zaccardo created BROOKLYN-439:
--

 Summary: Existing `userMetadata` cannot be used with WinRM 
deployments
 Key: BROOKLYN-439
 URL: https://issues.apache.org/jira/browse/BROOKLYN-439
 Project: Brooklyn
  Issue Type: Improvement
Affects Versions: 0.11.0
Reporter: Mike Zaccardo
Priority: Minor


When deploying a WinRM-based blueprint, the `userMetadata` of the deployment 
location's configuration must be empty. See: 
http://docs.cloudsoft.io/blueprints/base-blueprints/winrm/index.html#user-metadata-service-requirement

This prevents the user from deploying with any other potentially useful 
`userMetadata` values, like their email or a "keep" tag. It will also cause the 
WinRM deployment to fail if the user does not realize that s/he has existing 
`userMetadata` in place, and there is no relevant error message to make this 
clear.

Ideally the existing `userMetadata` could be merged with the necessary WinRM 
script so the user does not have to abandon their desired `userMetadata`.

The relevant code is here: 
https://github.com/apache/brooklyn-server/blob/master/locations/jclouds/src/main/java/org/apache/brooklyn/location/jclouds/JcloudsLocation.java#L1470



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Google Summer of Code

2017-02-08 Thread Mike Zaccardo 
Hi all,

As a general idea, perhaps a developer productivity enhancement for
Brooklyn would be a good summer project?

-Mike

On Tue, Feb 7, 2017 at 8:13 AM Richard Downer <rich...@apache.org> wrote:

> Hi all,
>
> Do we have any projects that we'd like to put forward for GSoC 2017?
>
> Apache has the structure and processes in place for GSoC so all we need to
> do is come up with ideas!
>
> The deadline for a list of ideas is Thursday (apologies for the short
> notice, due to illness I've been away and only just got the notification).
>
> Cheers
> Richard.
>
-- 

Mike Zaccardo

Senior Software Engineer

Skype: mike.cloudsoft

Twitter: @ItsMeMikeZ <https://twitter.com/ItsMeMikeZ> LinkedIn:
linkedin.com/in/mike-zaccardo
<https://www.linkedin.com/in/mike-zaccardo-aa3ab812>

[image: Cloudsoft Logo.jpg] <https://cloudsoft.io/>

Stay up to date with everything Cloudsoft:

[image: Twitter_Logo_White_On_Blue.png] <https://twitter.com/cloudsoft> [image:
YouTube-social-icon_red_48px.png]
<https://www.youtube.com/channel/UCpbLhvXrYWz8B_osUX6rn0Q>

Re: [CANCEL][VOTE] Release Apache Brooklyn 0.10.0 [rc3]

2016-12-21 Thread Mike Zaccardo 
st Classic (https) &
> >>> Karaf
> >>>>>> (non-https);
> >>>>>>
> >>>>>> [✓] Download links work.
> >>>>>> [✓] Binaries work.
> >>>>>> [✓] Checksums and PGP signatures are valid.
> >>>>>> [✓] Expanded source archive matches contents of RC tag.
> >>>>>> [✓] Expanded source archive builds and passes tests.
> >>>>>> [✓] LICENSE is present and correct.
> >>>>>> [✓] NOTICE is present and correct, including copyright date.
> >>>>>> [✓] All files have license headers where appropriate.
> >>>>>> [✓] All dependencies have compatible licenses.
> >>>>>> [✓] No compiled archives bundled in source archive.
> >>>>>> [-] I follow this project’s commits list.
> >>>>>>
> >>>>>>
> >>>>>> Svet.
> >>>>>>
> >>>>>>
> >>>>>>> On 18.12.2016 г., at 19:14, Aled Sage <aled.s...@gmail.com> wrote:
> >>>>>>>
> >>>>>>> +1 (binding)
> >>>>>>>
> >>>>>>> I downloaded the tar.gz, and ran it on OS X. I deployed
> TomcatServer
> >>> to
> >>>>>> AWS, Softlayer, Openstack (bluebox-london) and Google Compute
> Engine.
> >>>>>>> I ran the verify_brooklyn_rc.sh script (see attachment in rc1
> vote).
> >>>>>>>
> >>>>>>> I relied on the rat check when running `mvn clean install` for
> >>> checking
> >>>>>> that "all files have license headers where appropriate".
> >>>>>>> I checked that each tar.gz in [1] contained a top-level LICENSE and
> >>>>>> NOTICE file (including the text "Copyright 2014-2016 The Apache
> >>> Software
> >>>>>> Foundation").
> >>>>>>> [-] Download links work.
> >>>>>>> [-] Binaries work.
> >>>>>>> [x] Checksums and PGP signatures are valid.
> >>>>>>> [-] Expanded source archive matches contents of RC tag.
> >>>>>>> [x] Expanded source archive builds and passes tests.
> >>>>>>> [x] LICENSE is present and correct.
> >>>>>>> [x] NOTICE is present and correct, including copyright date.
> >>>>>>> [x] All files have license headers where appropriate.
> >>>>>>> [-] All dependencies have compatible licenses.
> >>>>>>> [x] No compiled archives bundled in source archive.
> >>>>>>> [x] I follow this project’s commits list.
> >>>>>>>
> >>>>>>> Aled
> >>>>>>>
> >>>>>>> [1]
> >>>>>> https://dist.apache.org/repos/dist/dev/brooklyn/apache-
> >>>> brooklyn-0.10.0-rc3
> >>>>>>>
> >>>>>>> On 16/12/2016 12:34, Svetoslav Neykov wrote:
> >>>>>>>> This is to call for a vote for the release of Apache Brooklyn
> >>> 0.10.0.
> >>>>>>>> This release comprises of a source code distribution, and a
> >>>>>> corresponding
> >>>>>>>> binary distribution, and Maven artifacts.
> >>>>>>>>
> >>>>>>>> The source and binary distributions, including signatures,
> digests,
> >>>>>> etc. can
> >>>>>>>> be found at:
> >>>>>>>>
> >>>>>>>>
> >>>>>> https://dist.apache.org/repos/dist/dev/brooklyn/apache-
> >>>> brooklyn-0.10.0-rc3
> >>>>>>>> The artifact SHA-256 checksums are as follows:
> >>>>>>>>
> >>>>>>>>  9ae6ec9f6e2356264fd2032d224965d191e5eab5a5346f8a9de5b05271650157
> >>>>>> *apache-brooklyn-0.10.0-rc3-1.noarch.rpm
> >>>>>>>>  b43c1fc20409594d17151d68b550bb17d8ea5a5592e0b7fbdcf489a81ca2118e
> >>>>>> *apache-brooklyn-0.10.0-rc3-bin.tar.gz
> >>>>>>>>  cb7df99f024e918c5517097d904a68d9976c5bf913c9dd64edebb6b5b6e5a89e
> >>>>>> *apache-brooklyn-0.10.0-rc3-bin.zip
> >>>>>>>>  d65d2525507d40fa0b554b13a57190a724213610a7615082d53137b7bab4b5d5
> >>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-linux.tar.gz
> >>>>>>>>  4d13118fca8e02aaf5b4ab3b3f305d139450bcf64d290781609643c4622b8cb5
> >>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-linux.zip
> >>>>>>>>  375eb6a4944a7758dc790a75bd4a0abc782a4ba66af754b4162bbb66a33902d8
> >>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-macosx.tar.gz
> >>>>>>>>  9d95e0679e603a9184ada88b63b0c4e8f8503eb51677e04ae59f4aa05f454860
> >>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-macosx.zip
> >>>>>>>>  502e0999d3612f0eb4027d24312da67a67183fc127074ec815b3c72f5de41d87
> >>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-windows.tar.gz
> >>>>>>>>  1e1ec0210e53faaf9ef1d8907275535a197b341df80e0832067967f4075db191
> >>>>>> *apache-brooklyn-0.10.0-rc3-client-cli-windows.zip
> >>>>>>>>  a32c65628bf897c66ed8bd820a2ce5268bba52815b46f805795e9b51ac836912
> >>>>>> *apache-brooklyn-0.10.0-rc3-karaf.tar.gz
> >>>>>>>>  4b840de7ab986ba64ffba4b98748ca87818718ac3e386bb2d978533e4fa35f62
> >>>>>> *apache-brooklyn-0.10.0-rc3-karaf.zip
> >>>>>>>>  7906b3dba2278c9648f2b340a532d3030536a6a8f1c920311bdcd585a42111e8
> >>>>>> *apache-brooklyn-0.10.0-rc3-src.tar.gz
> >>>>>>>>  4579e5e27c2751b5e8b57bab126ae683aa34aa42d6e13eb6c922951df6947b4c
> >>>>>> *apache-brooklyn-0.10.0-rc3-src.zip
> >>>>>>>>  b361ada2d4cc1334e72b44986b96e6302aaa24464252c3782f7b679bfa5da858
> >>>>>> *apache-brooklyn-0.10.0-rc3-vagrant.tar.gz
> >>>>>>>>  393df963f6b952ec8c05c1aa0ab0d459037e0972798f17ba7d0221f7e3570440
> >>>>>> *apache-brooklyn-0.10.0-rc3-vagrant.zip
> >>>>>>>> The Nexus staging repository for the Maven artifacts is located
> at:
> >>>>>>>>
> >>>>>>>>
> >>>>>> https://repository.apache.org/content/repositories/
> >>>> orgapachebrooklyn-1034
> >>>>>>>> All release artifacts are signed with the following key:
> >>>>>>>>
> >>>>>>>>https://people.apache.org/keys/committer/svet.asc
> >>>>>>>>
> >>>>>>>> KEYS file available here:
> >>>>>>>>
> >>>>>>>>https://dist.apache.org/repos/dist/release/brooklyn/KEYS
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> The artifacts were built from git commit IDs:
> >>>>>>>>
> >>>>>>>> brooklyn: 1d7ab19ffba2c87e9ad1b037fb217dc7d39506c9
> >>>>>>>> brooklyn-client: 0e870fa15714c5a050bb67d6fa0429ff90a8fa4c
> >>>>>>>> brooklyn-dist: dda655c45abab34601a5e62250431ea93fdf1755
> >>>>>>>> brooklyn-docs: d75752725ef6683a0f52e3059ed475dc69872f9e
> >>>>>>>> brooklyn-library: 9fbc78cb4a9d1dccdbdbb70a1ee48f2afddfe067
> >>>>>>>> brooklyn-server: 41561635e3bbb0524dbeaae516a26c793174fd93
> >>>>>>>> brooklyn-ui: a6e2e8bccfdd98b4f7155b5be86f5b85149e0f33
> >>>>>>>> All of the above have been tagged as "apache-brooklyn-0.10.0-rc3"
> >>>>>>>>
> >>>>>>>> Please vote on releasing this package as Apache Brooklyn 0.10.0.
> >>>>>>>>
> >>>>>>>> The vote will be open for at least 72 hours.
> >>>>>>>> [ ] +1 Release this package as Apache Brooklyn 0.10.0
> >>>>>>>> [ ] +0 no opinion
> >>>>>>>> [ ] -1 Do not release this package because ...
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Thanks!
> >>>>>>>> Svet.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> CHECKLIST for reference
> >>>>>>>>
> >>>>>>>> [ ] Download links work.
> >>>>>>>> [ ] Binaries work.
> >>>>>>>> [ ] Checksums and PGP signatures are valid.
> >>>>>>>> [ ] Expanded source archive matches contents of RC tag.
> >>>>>>>> [ ] Expanded source archive builds and passes tests.
> >>>>>>>> [ ] LICENSE is present and correct.
> >>>>>>>> [ ] NOTICE is present and correct, including copyright date.
> >>>>>>>> [ ] All files have license headers where appropriate.
> >>>>>>>> [ ] All dependencies have compatible licenses.
> >>>>>>>> [ ] No compiled archives bundled in source archive.
> >>>>>>>> [ ] I follow this project’s commits list.
> >>>>>>>
> >>>>>>
> >>>>
> >
>
> --
Mike Zaccardo
Senior Engineer
Skype: mike.cloudsoft
Twitter: @ItsMeMikeZ <https://twitter.com/itsmemikez>

<http://cloudsoft.io/>
Stay up to date with everything Cloudsoft:
[image: header-logo.png] <https://twitter.com/cloudsoft>[image:
you-tube-video-logo-download-png.png]
<https://www.youtube.com/channel/UCpbLhvXrYWz8B_osUX6rn0Q>

Re: How to Override `imageID` of a Preconfigured Location?

2016-10-20 Thread Mike Zaccardo 
Great, the parent `brooklyn.properties` solution works for me.

On Thu, Oct 20, 2016 at 8:04 PM Aled Sage <aled.s...@gmail.com> wrote:

> My email client seems to have messed up the indents! Here it is again
> with a comment on each line saying what the indent should be!
>
> ```
> name: Server (Brooklyn Example)
> location:
>aws-ec2-us-east-1: # two spaces indent
>  imageId: us-east-1/ami-6224a40a # four spaces indent
> services:
> - type: server
>name: My VM # two spaces indent
> ```
>
> ```
> name: Multiple Servers (Brooklyn Example)
> location:aws-ec2-us-east-1
> services:
> - type: org.apache.brooklyn.entity.stock.BasicApplication
>brooklyn.config: # two spaces indent
>  provisioning.properties: # 4 spaces indent
>imageId: us-east-1/ami-6224a40a # 6 spaces indent
>brooklyn.children: # 2 spaces indent
>- type: server # 2 spaces indent
>  name: vm1 # 4 spaces indent
>- type: server # 2 spaces indent
>  name: vm2 # 4 spaces indent
> ```
>
> On 21/10/2016 00:42, Aled Sage wrote:
> > Hi Mike,
> >
> > Off the top of my head, I'd expect it to be:
> >
> > ```
> > name: Server (Brooklyn Example)
> > location:
> > aws-ec2-us-east-1:
> > imageId: us-east-1/ami-6224a40a
> > services:
> > - type: server
> >   name: My VM
> > ```
> >
> > Alternatively (less good), you could rely on inheriting the
> > "provisioning.properties" in the runtime management hierarchy so that
> > all servers in that part of the tree get the config (see docs at
> > https://github.com/apache/brooklyn-docs/pull/115/files). For example,
> > something like:
> >
> > ```
> > name: Multiple Servers (Brooklyn Example)
> > location:aws-ec2-us-east-1
> > services:
> > - type: org.apache.brooklyn.entity.stock.BasicApplication
> >   brooklyn.config:
> > provisioning.properties:
> >   imageId: us-east-1/ami-6224a40a
> >   brooklyn.children:
> >   - type: server
> > name: vm1
> >   - type: server
> > name: vm2
> > ```
> >
> > Aled
> >
> >
> > On 21/10/2016 00:31, Mike Zaccardo wrote:
> >> Hi dev,
> >>
> >> I'd like to override the `imageID` of a location so it applies to all
> >> entities in a blueprint. Consider this simple blueprint:
> >>
> >> ```
> >> name: Server (Brooklyn Example)
> >>
> >> location: aws-ec2-us-east-1
> >>
> >> services:
> >> - type: server
> >>name: My VM
> >>provisioning.properties:
> >>  imageId: us-east-1/ami-6224a40a
> >> ```
> >>
> >> This will successfully deploy a VM to my preconfigured location named
> >> `aws-ec2-us-east-1` with the desired AMI `us-east-1/ami-6224a40a`.
> >> However,
> >> I'd like to add more services to this blueprint but do not want to
> >> have to
> >> specify `provisioning.properties` and `imageId` for each one. What is
> >> the
> >> proper syntax to set the `imageId` for the location itself so that it
> >> will
> >> apply to all entities?
> >>
> >> Thanks,
> >> Mike
> >>
> >
>
>

Re: How to Override `imageID` of a Preconfigured Location?

2016-10-20 Thread Mike Zaccardo 
Thanks guys.

My real use case is deploying a template item from the UI, which is the
parent of all other entities being deployed. Therefore Aled's suggestion of
adding the `provisioning.properties` to `brooklyn.config` of the parent, in
this case the template item, should work. I'll report back.

-Mike

On Thu, Oct 20, 2016 at 7:47 PM Aled Sage <aled.s...@gmail.com> wrote:

> Hi Mike,
>
> Off the top of my head, I'd expect it to be:
>
> ```
> name: Server (Brooklyn Example)
> location:
> aws-ec2-us-east-1:
>  imageId: us-east-1/ami-6224a40a
> services:
> - type: server
>name: My VM
> ```
>
> Alternatively (less good), you could rely on inheriting the
> "provisioning.properties" in the runtime management hierarchy so that
> all servers in that part of the tree get the config (see docs at
> https://github.com/apache/brooklyn-docs/pull/115/files). For example,
> something like:
>
> ```
> name: Multiple Servers (Brooklyn Example)
> location:aws-ec2-us-east-1
> services:
> - type: org.apache.brooklyn.entity.stock.BasicApplication
>brooklyn.config:
>  provisioning.properties:
>imageId: us-east-1/ami-6224a40a
>brooklyn.children:
>- type: server
>  name: vm1
>- type: server
>  name: vm2
> ```
>
> Aled
>
>
> On 21/10/2016 00:31, Mike Zaccardo wrote:
> > Hi dev,
> >
> > I'd like to override the `imageID` of a location so it applies to all
> > entities in a blueprint. Consider this simple blueprint:
> >
> > ```
> > name: Server (Brooklyn Example)
> >
> > location: aws-ec2-us-east-1
> >
> > services:
> > - type: server
> >name: My VM
> >provisioning.properties:
> >  imageId: us-east-1/ami-6224a40a
> > ```
> >
> > This will successfully deploy a VM to my preconfigured location named
> > `aws-ec2-us-east-1` with the desired AMI `us-east-1/ami-6224a40a`.
> However,
> > I'd like to add more services to this blueprint but do not want to have
> to
> > specify `provisioning.properties` and `imageId` for each one. What is the
> > proper syntax to set the `imageId` for the location itself so that it
> will
> > apply to all entities?
> >
> > Thanks,
> > Mike
> >
>
>

Re: How to Override `imageID` of a Preconfigured Location?

2016-10-20 Thread Mike Zaccardo 
That URL above refers to:

location:
  whatever-location-they-have-configured:
  brooklyn.config:
imageId: ami-12345

The YAML parser complains about this, and if I move `brooklyn.config` to
the same indentation as `location` then it does not apply the `imageId`
properly.

On Thu, Oct 20, 2016 at 7:39 PM Andrea Turli <andrea.tu...@cloudsoftcorp.com>
wrote:

> Cant test it now but is this not working?
>
> https://cloudsoftcorp.slack.com/archives/D1Z6Z28MU/p147697807243
>
> Il 21/ott/2016 00:31, "Mike Zaccardo" <mike.zacca...@cloudsoftcorp.com> ha
> scritto:
>
> > Hi dev,
> >
> > I'd like to override the `imageID` of a location so it applies to all
> > entities in a blueprint. Consider this simple blueprint:
> >
> > ```
> > name: Server (Brooklyn Example)
> >
> > location: aws-ec2-us-east-1
> >
> > services:
> > - type: server
> >   name: My VM
> >   provisioning.properties:
> > imageId: us-east-1/ami-6224a40a
> > ```
> >
> > This will successfully deploy a VM to my preconfigured location named
> > `aws-ec2-us-east-1` with the desired AMI `us-east-1/ami-6224a40a`.
> However,
> > I'd like to add more services to this blueprint but do not want to have
> to
> > specify `provisioning.properties` and `imageId` for each one. What is the
> > proper syntax to set the `imageId` for the location itself so that it
> will
> > apply to all entities?
> >
> > Thanks,
> > Mike
> >
>

How to Override `imageID` of a Preconfigured Location?

2016-10-20 Thread Mike Zaccardo 
Hi dev,

I'd like to override the `imageID` of a location so it applies to all
entities in a blueprint. Consider this simple blueprint:

```
name: Server (Brooklyn Example)

location: aws-ec2-us-east-1

services:
- type: server
  name: My VM
  provisioning.properties:
imageId: us-east-1/ami-6224a40a
```

This will successfully deploy a VM to my preconfigured location named
`aws-ec2-us-east-1` with the desired AMI `us-east-1/ami-6224a40a`. However,
I'd like to add more services to this blueprint but do not want to have to
specify `provisioning.properties` and `imageId` for each one. What is the
proper syntax to set the `imageId` for the location itself so that it will
apply to all entities?

Thanks,
Mike

Children of VanillaSoftwareProcess and service.isUp

2016-09-30 Thread Mike Zaccardo 
Hi,

I have a blueprint that consists of a `VanillaSoftwareProcess` (VSP) with a
number of children entities. If any of these children go on fire, the
parent VSP still reports as healthy, but I'd really like it to go on fire
as well. In other words, I want the parent VSP to report as healthy if and
only if all of its children are also healthy. Is this achievable in YAML /
how do I go about doing that?

Here is an example blueprint which showcases this issue:
https://gist.github.com/mikezaccardo/227d00f0a90ed46ad7350b067e416bf4. Once
deployed, you can cause a child entity to go on fire simply by removing the
file that is checked. At this point even though the child entity is on fire
the, parent will remain green.

Thanks,
Mike

Re: [PROPOSAL] Remove unauthenticated localhost login

2016-09-08 Thread Mike Zaccardo 
+0.  My hesitation is the con of more difficult first user experience.
Could a compromise be that localhost login works unauthenticated the first
time but immediately prompts the user to set a username and password?

On Thu, Sep 8, 2016 at 10:12 AM Aled Sage  wrote:

> Hi all,
>
> I'd like to remove from Brooklyn the feature where you can login
> authenticated from localhost.
> _*
> Current Situation*_
> When you first start Brooklyn on a new machine (so no
> brooklyn.properties etc), it will auto-generate an initial username +
> password and log that. For example:
>
> 2016-09-08 15:03:48,631 INFO  No security provider options
> specified. Define a security provider or users to prevent a random
> password being created and logged.
> 2016-09-08 15:03:48,632 INFO  Starting Brooklyn web-console with
> passwordless access on localhost and protected access from any other
> interfaces (no bind address specified)
> 2016-09-08 15:03:48,633 INFO  Allowing access to web console from
> localhost or with brooklyn:sgZZL9qqBd
> 2016-09-08 15:03:50,572 INFO  Started Brooklyn console at
> http://127.0.0.1:8083/, running classpath://brooklyn.war@
>
> If you connect from localhost, you can login without any credentials.
>
> If you connect from an external IP, you will need to use those credentials.
>
> _*Pros and Cons*_
> This is convenient for first-time users (they don't need to worry about
> setting up a username/password if running Brooklyn on their local
> machine). We have to explain a little less before they can try out AMP.
>
> But it will also feel like a security hole.
>
> It will makes the experience of installing Brooklyn on a server very
> different from the localhost experience. This is particularly true as we
> encourage the use of RPM/DEB for installing Brooklyn.
>
> _*Proposal*_
> I propose removing this, so localhost logins also require credentials.
>
> We'd also ensure the docs point at the username:password for accessing
> the web-console. It is a problem that we don't already call this out
> (e.g. at
>
> http://brooklyn.apache.org/v/latest/start/running.html#control-apache-brooklyn
> and http://brooklyn.apache.org/v/latest/ops/gui/running.html) because
> users installing on a server will not know what to do.
>
> Aled
>
>

Re: Patching existing applications

2016-07-19 Thread Mike Zaccardo 
Hi Graham,

I don't have a complete answer for you now as this isn't my particular area
of expertise, but I can get you started and will ask around for more
information in order to provide a fuller answer.

I believe this functionality can be achieved using a combination of an
effector and the `ServiceReplacer` policy.  Here are two examples[1][2] of
this policy in use.  My understanding is that the service could be replaced
with a new instance running an upgraded version, on demand.  I will confirm
this.

I hope this helps for starters.

Cheers,
Mike

[1] https://brooklyn.apache.org/v/latest/start/policies.html
[2] https://brooklyn.apache.org/v/latest/java/topology-dependencies.html

On Tue, Jul 19, 2016 at 2:20 PM Graham Ashby 
wrote:

> I've been investigating using Brooklyn with our product.  I've been
> impressed with the out of box capabilities, plus the ease of extending it.
>
> However, one thing I haven't seen addressed in the documentation is how
> you patch running systems.  Say I have a composite application that has a
> number of subsidiary applcations.  Now of those, there are a number of
> replicated components tat all need upgrading.  How do I do this?  I would
> have the blueprint for the entire system.  How do I indicate that certain
> parts need updating?  I don't want to have to tear down the existing
> system, and rebuild a new one.
>
> Sorry if this is muddled -- I'm new to Brooklyn.
>
> Thanks
> Graham Ashby
> IBM Canada
>
>

Re: [PROPOSAL] catalog YAML format consistency

2016-06-28 Thread Mike Zaccardo 
+1 for agreeing upon a standard syntax, especially because consulting
existing blueprints is one of the best references when developing a new one.

Alex's staged plan also makes sense to me.

On Mon, Jun 27, 2016 at 8:28 AM Andrew Kennedy <
andrew.kenn...@cloudsoftcorp.com> wrote:

> +1
>
> I agree that we need to maintain consistency in our YAML and BOM files, but
> not just at the level of Brooklyn item and entity syntax. There should also
> be a consistent structural format to the files. For example, when
> specifying configuration, we allow items both inside the `brooklyn.config`
> map, and outside it. For short examples, missing out `brooklyn.config` is
> acceptable, but in general we should use it. There should also be
> consistency in ordering the parts of an entity or catalog entry definition,
> as well as the formatting of maps, lists and strings.
>
> The following is a suggested style guide, for discussion.
>
> - https://gist.github.com/grkvlt/62ee0ddeea2f4503f82ad25c2f9b31fd
>
> The normative statements are listed here, and the document linked above
> contains a conforming YAML fragment showing how they are interpreted.
>
> 1. Blueprints MUST place all configuration inside a `brooklyn.config` map,
> and MUST use the fully qualified configuration key name
> 2. Lists MUST be indented properly, to allow IDE folding to work properly
> 3. Keywords MUST be formatted as `lowerCamel` tokens
> 4. Sensor, configuration key and section names MUST be formatted as
> `lower-hyphen.dot-separated` tokens
> 5. The preamble for a catalog entry SHOULD contain the following keys,
> which MUST appear in this order: version, id, name, description, iconUrl,
> origin, license, licenseUrl, publish
> 6. Entities SHOULD contain the following sections, which MUST appear in
> this order: brooklyn.parameters, brooklyn.config, brooklyn.initializers,
> brooklyn.enrichers, brooklyn.policies, brooklyn.children
> 7. Catalog items SHOULD contain the following keys, which MUST appear in
> this order: id, name, description, itemType, item
> 8. Entities and entity specifications SHOULD contain the following keys,
> which MUST appear in this order: type, id, name, description, services
> 9. Names MUST be quoted strings
> 10. The description value MUST use the multi-line string syntax
> 11. Parameters SHOULD use the following keys, which MUST appear in this
> order: name, label, description, type, default, constraints
>
> Andrew.
>
>
> On Mon, 20 Jun 2016 at 18:08 Aled Sage  wrote:
>
> > Thanks all,
> >
> > Alex's suggestion makes a lot of sense. So we should:
> >
> >  1. agree short-term preferred syntax
> >  2. update our docs and examples to *always* use that
> >  3. discuss improvements for a more powerful syntax, and the longer term
> > bigger long-term overhaul.
> >
> > It should be trivial to warn someone if they have not included the
> > "itemType", so I think we should do that short-term.
> >
> > ---
> > Any more opinions for the preferred syntax?
> >
> > Aled
> >
> >
> > On 20/06/2016 14:44, Geoff Macartney wrote:
> > > +1 for the proposal, and for staging it.
> > >
> > > I actually quite like the suggestion of making items/item entirely
> > consistent (by requiring both).   If I have
> > >
> > > 1 brooklyn.catalog:
> > > 2   version: "2.0.0-SNAPSHOT"
> > > 3
> > > 4   item:
> > > 5 type: server
> > > 6 id: testy
> > > 7 name: Testy McServer
> > >
> > > and decide for some reason that I need a second item (maybe move one
> > here from another file), I can’t just add it below line 7.  Instead I
> have
> > to go editing lines 3-7 to add “items:” and change the indentation.
> > Sticking to items+item consistently will make this sort of refactoring
> less
> > tedious.  Just a thought.
> > >
> > > Geoff
> > >
> > >
> > >
> > >
> > > 
> > > Gnu PGP key - http://is.gd/uI
> > >
> > >
> > >> On 20 Jun 2016, at 14:17, Svetoslav Neykov <
> > svetoslav.ney...@cloudsoftcorp.com> wrote:
> > >>
> > >> +1 for the proposal.
> > >>
> > >> I find the current item-items functionality logical. "item" is used in
> > leaf items, "items" is used in non-leaf items. Forcing a non-leaf root
> just
> > so we always have "items" is overhead.
> > >>
> > >> Svet.
> > >>
> > >>
> > >>> On 20.06.2016 г., at 15:47, Aled Sage  wrote:
> > >>>
> > >>> Hi all,
> > >>>
> > >>> The YAML format for adding catalog items accepts several different
> > ways of defining them. This has led to our examples being inconsistent,
> our
> > code more complicated, and potential confusion for users when they see
> > different things that turn out to mean the same.
> > >>>
> > >>> I think we should standardise on one approach, and deprecate the
> other
> > ways.
> > >>>
> > >>> ---
> > >>>
> > >>> _*Current Code*_
> > >>>
> > >>> An example .bom file is shown below:
> > >>>
> > >>>brooklyn.catalog:
> > >>> items:
> > >>> - id: entity1
> > >>>version: "1.0.0"
> > >>>itemType: entity
> >

[jira] [Created] (BROOKLYN-270) BYON Location GUI Generates Bad-formatted YAML File

2016-05-18 Thread Mike Zaccardo (JIRA) 
Mike Zaccardo created BROOKLYN-270:
--

 Summary: BYON Location GUI Generates Bad-formatted YAML File
 Key: BROOKLYN-270
 URL: https://issues.apache.org/jira/browse/BROOKLYN-270
 Project: Brooklyn
  Issue Type: Bug
Affects Versions: 0.9.0
 Environment: Mac OS X 10.11.4
Reporter: Mike Zaccardo


When attempting to add a BYON location with a private key file through the GUI, 
the generated YAML file is improperly formatted and results in the following 
error when the user tries to save:

ERROR Invalid YAML: while scanning a simple key; could not found expected ':'; 
in 'reader', line 12, column 1: vfyF2M3xG3z5MUPuqeCveLhkI/1t26mW ... ^

The location can only be added after the user manually fixes the formatting in 
the YAML editor view.

Here is a comparison of generated vs. manually fixed: 
https://gist.github.com/mikezaccardo/34ea0c38b232bf125a059f1b1913c486



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Nice-to-have: Built-in Cluster Sensor List Generator

2016-05-05 Thread Mike Zaccardo 
Hi all,

I've encountered the following task numerous times when authoring
`DynamicCluster` blueprints: write a sensor that returns a comma separated
list of values for each member of a cluster (e.g. the host address of each
member).

This is currently how to achieve such a task:

  brooklyn.enrichers:
  - type: org.apache.brooklyn.enricher.stock.Aggregator
brooklyn.config:
  uniqueTag: member-address-aggregator
  enricher.aggregator.excludeBlank: true
  enricher.aggregating.fromMembers: true
  enricher.sourceSensor: $brooklyn:sensor("member.host.address")
  enricher.targetSensor:
$brooklyn:sensor("member.host.address.list")

  - type: org.apache.brooklyn.enricher.stock.Joiner
brooklyn.config:
  uniqueTag: member-address-joiner
  enricher.sourceSensor:
$brooklyn:sensor("member.host.address.list")
  enricher.targetSensor:
$brooklyn:sensor("member.host.address.list.comma_separated")
  minimum: $brooklyn:config("cluster.size")
  separator: ","
  quote: false

And here[1] is a specific example in a real blueprint.

That's pretty verbose for a commonly required task.  Instead, it would be
nice to have something resembling the following:

  brooklyn.enrichers:
  - type: org.apache.brooklyn.enricher.stock.ClusterListGenerator
brooklyn.config:
  uniqueTag: member-address-list-generator
  enricher.sourceSensor: $brooklyn:sensor("member.host.address")
  enricher.targetSensor:
$brooklyn:sensor("member.host.address.list")

Short and sweet!  WDYT?

-Mike

[1]
https://github.com/cloudsoft/brooklyn-tendermint/blob/master/tendermint-mintnet.bom#L82

Re: [VOTE] Accept contribution of Brooklyn CLI

2016-02-18 Thread Mike Zaccardo 
+1

On Thu, Feb 18, 2016 at 10:33 AM Alex Heneveld <
alex.henev...@cloudsoftcorp.com> wrote:

>
> +1 binding
>
> Alex
>
> On 18/02/2016 18:14, Svetoslav Neykov wrote:
> > +1 binding
> >
> > Svet.
> >
> >
> >> On 18.02.2016 г., at 18:09, Duncan Johnston Watt <
> duncan.johnstonw...@cloudsoftcorp.com> wrote:
> >>
> >> +1
> >>
> >> Duncan Johnston-Watt
> >> CEO | Cloudsoft Corporation
> >>
> >> Twitter | @duncanjw
> >> Mobile | +44 777 190 2653
> >> Skype | duncan_johnstonwatt
> >> Linkedin | www.linkedin.com/in/duncanjohnstonwatt
> >>
> >> On 18 February 2016 at 15:25, Richard Downer 
> wrote:
> >>
> >>> All,
> >>>
> >>> https://github.com/apache/brooklyn-client/pull/1 adds the Brooklyn
> >>> CLI. This allows a user to control and script Brooklyn from the
> >>> command line. It opens up many possibilities, including making the web
> >>> UI optional (reducing the security footprint in production
> >>> deployments), allowing admins to script Brooklyn using shell scripts,
> >>> and simplifies our getting started tutorials. It's a very compelling
> >>> addition to the Brooklyn project.
> >>>
> >>> The CLI was developed in a non-Apache location starting last year,
> >>> with the bulk of development happening from November onwards. It has
>  150 commits from 4 authors and is over 6,000 SLOC. Given the size of
> >>> the contribution, it is prudent to follow Apache's IP clearance
> >>> process before merging the PR.
> >>>
> >>> This vote is to discover if the Brooklyn PMC and community are in
> >>> favour of accepting this contribution. If the vote passes, the PMC and
> >>> the authors of the code will work together to complete Apache's IP
> >>> Clearance process and merge the code for the CLI.
> >>>
> >>> This vote will be open for at least 72 hours (i.e. 15:30 UTC on Sunday
> >>> 21st February 2016)
> >>>
> >>> [ ] +1, accept contribution of the Brooklyn CLI into the project
> >>> [ ] 0, no opinion
> >>> [ ] -1, reject contribution because...
> >>>
> >>> Thanks,
> >>> Richard.
> >>>
>
>

Re: YAML Blueprints Failing to Stop

2015-12-03 Thread Mike Zaccardo 
Problem reduced to simpler and more generic terms:

-Stop is called on a BasicApplication "A"
-Stop is then called on A's children, X and Y, in parallel[1]
-Y has a `shell.env` value which is an `attributeWhenReady` of a value from
X
-Y hangs infinitely trying to resolve the value from X which has already
stopped, so Y never stops

Potential solutions:

-More complicated to implement but more robust: Brooklyn analyzes children
entities and detects these types of dependencies, and then schedules the
shutdown process accordingly, resulting in safe sequential shut down vs
currently broken parallel shutdown.

-Simpler to implement but puts the onus on the blueprint author: add a
value to the DSL which represents a numerical dependency hierarchy. In this
case, X would have a value of 1 and Y would have a value of 2 (assigned in
the YAML blueprint). Upon stop, the entities will stop sequentially in
decreasing numerical order (2->Y and then 1->X).

WDYT?

-Mike

[1]
https://github.com/apache/incubator-brooklyn/blob/master/core/src/main/java/org/apache/brooklyn/core/entity/trait/StartableMethods.java#L59

On Wed, Dec 2, 2015 at 8:52 PM Mike Zaccardo <
mike.zacca...@cloudsoftcorp.com> wrote:

> Hi all,
>
> When attempting to stop some of my more complicated YAML blueprints I have
> encountered situations where certain entities will hang on the stop phase,
> preventing the application from disappearing.
>
> Below is a dummy example which demonstrates the problem.  Note that this
> makes use of the `all.members.up` sensor which is not in master, so my
> branch[1] must be used if you'd like to run it yourself.
>
> BOM file: https://gist.github.com/mikezaccardo/39cc5065c10efde765d5
> YAML file: https://gist.github.com/mikezaccardo/06dc8ba981694c983399
>
> When the "Cluster Stop Test" entity is expunged, the "Core Cluster" entity
> will stop correctly, but the "Secondary Cluster Entity" will hang.  This
> occurs because each of the secondary cluster members will fail to resolve a
> dependent value, specifically stuck on `Retrieving
> $brooklyn:entity("my-core-cluster").attributeWhenReady("host.address.list.comma_separated")`
> because the core cluster has already shut down.
>
> However, if I debug and add a breakpoint to `DynamicClusterImpl` stop
> method, and manually ensure that the "Secondary Cluster" stops first before
> "Core Cluster", then the expunge will proceed fully without error.
>
> The reason why I am not fully convinced that this is a Brooklyn bug is
> because I reference the "my-core-cluster" ID in the BOM file, yet this is
> an ID that is specified in the YAML file, which to me is a bad smell.  Is
> that, in fact, bad practice from a blueprinting perspective?  If so then I
> do not know how I'd properly reference that cluster by ID in the BOM.
>
> WDYT?  I'd be glad to 1:1 with someone to think through this more.
>
> Cheers,
> Mike
>
> [1]
> https://github.com/mikezaccardo/incubator-brooklyn/tree/all-members-up-sensor
>
>
>

YAML Blueprints Failing to Stop

2015-12-02 Thread Mike Zaccardo 
Hi all,

When attempting to stop some of my more complicated YAML blueprints I have
encountered situations where certain entities will hang on the stop phase,
preventing the application from disappearing.

Below is a dummy example which demonstrates the problem.  Note that this
makes use of the `all.members.up` sensor which is not in master, so my
branch[1] must be used if you'd like to run it yourself.

BOM file: https://gist.github.com/mikezaccardo/39cc5065c10efde765d5
YAML file: https://gist.github.com/mikezaccardo/06dc8ba981694c983399

When the "Cluster Stop Test" entity is expunged, the "Core Cluster" entity
will stop correctly, but the "Secondary Cluster Entity" will hang.  This
occurs because each of the secondary cluster members will fail to resolve a
dependent value, specifically stuck on `Retrieving
$brooklyn:entity("my-core-cluster").attributeWhenReady("host.address.list.comma_separated")`
because the core cluster has already shut down.

However, if I debug and add a breakpoint to `DynamicClusterImpl` stop
method, and manually ensure that the "Secondary Cluster" stops first before
"Core Cluster", then the expunge will proceed fully without error.

The reason why I am not fully convinced that this is a Brooklyn bug is
because I reference the "my-core-cluster" ID in the BOM file, yet this is
an ID that is specified in the YAML file, which to me is a bad smell.  Is
that, in fact, bad practice from a blueprinting perspective?  If so then I
do not know how I'd properly reference that cluster by ID in the BOM.

WDYT?  I'd be glad to 1:1 with someone to think through this more.

Cheers,
Mike

[1]
https://github.com/mikezaccardo/incubator-brooklyn/tree/all-members-up-sensor