Build failed in Jenkins: brooklyn-master-windows #101

2016-05-06 Thread Apache Jenkins Server
See 

--
[...truncated 46705 lines...]
[JENKINS] Archiving 
F:\hudson\hudson-slave\workspace\brooklyn-master-windows\brooklyn-server\utils\groovy\target\brooklyn-utils-groovy-0.10.0-SNAPSHOT.jar
 to 
org.apache.brooklyn/brooklyn-utils-groovy/0.10.0-SNAPSHOT/brooklyn-utils-groovy-0.10.0-SNAPSHOT.jar
[JENKINS] Archiving 
F:\hudson\hudson-slave\workspace\brooklyn-master-windows\brooklyn-server\utils\groovy\target\brooklyn-utils-groovy-0.10.0-SNAPSHOT-tests.jar
 to 
org.apache.brooklyn/brooklyn-utils-groovy/0.10.0-SNAPSHOT/brooklyn-utils-groovy-0.10.0-SNAPSHOT-tests.jar
[JENKINS] Archiving 
F:\hudson\hudson-slave\workspace\brooklyn-master-windows\brooklyn-server\utils\groovy\target\brooklyn-utils-groovy-0.10.0-SNAPSHOT-sources.jar
 to 
org.apache.brooklyn/brooklyn-utils-groovy/0.10.0-SNAPSHOT/brooklyn-utils-groovy-0.10.0-SNAPSHOT-sources.jar
[JENKINS] Archiving 
F:\hudson\hudson-slave\workspace\brooklyn-master-windows\brooklyn-server\utils\groovy\target\brooklyn-utils-groovy-0.10.0-SNAPSHOT-test-sources.jar
 to 
org.apache.brooklyn/brooklyn-utils-groovy/0.10.0-SNAPSHOT/brooklyn-utils-groovy-0.10.0-SNAPSHOT-test-sources.jar
No artifacts from brooklyn-master-windows » Brooklyn Groovy Utilities #100 to 
compare, so performing full copy of artifacts
[JENKINS] Archiving 
F:\hudson\hudson-slave\workspace\brooklyn-master-windows\brooklyn-library\examples\simple-web-cluster\pom.xml
 to 
org.apache.brooklyn.example/brooklyn-example-simple-web-cluster/0.10.0-SNAPSHOT/brooklyn-example-simple-web-cluster-0.10.0-SNAPSHOT.pom
[JENKINS] Archiving 
F:\hudson\hudson-slave\workspace\brooklyn-master-windows\brooklyn-library\examples\simple-web-cluster\target\brooklyn-example-simple-web-cluster-0.10.0-SNAPSHOT.jar
 to 
org.apache.brooklyn.example/brooklyn-example-simple-web-cluster/0.10.0-SNAPSHOT/brooklyn-example-simple-web-cluster-0.10.0-SNAPSHOT.jar
[JENKINS] Archiving 
F:\hudson\hudson-slave\workspace\brooklyn-master-windows\brooklyn-library\examples\simple-web-cluster\target\brooklyn-example-simple-web-cluster-0.10.0-SNAPSHOT-tests.jar
 to 
org.apache.brooklyn.example/brooklyn-example-simple-web-cluster/0.10.0-SNAPSHOT/brooklyn-example-simple-web-cluster-0.10.0-SNAPSHOT-tests.jar
[JENKINS] Archiving 
F:\hudson\hudson-slave\workspace\brooklyn-master-windows\brooklyn-library\examples\simple-web-cluster\target\brooklyn-example-simple-web-cluster-0.10.0-SNAPSHOT-sources.jar
 to 
org.apache.brooklyn.example/brooklyn-example-simple-web-cluster/0.10.0-SNAPSHOT/brooklyn-example-simple-web-cluster-0.10.0-SNAPSHOT-sources.jar
[JENKINS] Archiving 
F:\hudson\hudson-slave\workspace\brooklyn-master-windows\brooklyn-library\examples\simple-web-cluster\target\brooklyn-example-simple-web-cluster-0.10.0-SNAPSHOT-test-sources.jar
 to 
org.apache.brooklyn.example/brooklyn-example-simple-web-cluster/0.10.0-SNAPSHOT/brooklyn-example-simple-web-cluster-0.10.0-SNAPSHOT-test-sources.jar
Compressed 7.56 MB of artifacts by 96.8% relative to #96
[JENKINS] Archiving 
F:\hudson\hudson-slave\workspace\brooklyn-master-windows\brooklyn-server\locations\jclouds\pom.xml
 to 
org.apache.brooklyn/brooklyn-locations-jclouds/0.10.0-SNAPSHOT/brooklyn-locations-jclouds-0.10.0-SNAPSHOT.pom
[JENKINS] Archiving 
F:\hudson\hudson-slave\workspace\brooklyn-master-windows\brooklyn-server\locations\jclouds\target\brooklyn-locations-jclouds-0.10.0-SNAPSHOT.jar
 to 
org.apache.brooklyn/brooklyn-locations-jclouds/0.10.0-SNAPSHOT/brooklyn-locations-jclouds-0.10.0-SNAPSHOT.jar
[JENKINS] Archiving 
F:\hudson\hudson-slave\workspace\brooklyn-master-windows\brooklyn-server\locations\jclouds\target\brooklyn-locations-jclouds-0.10.0-SNAPSHOT-tests.jar
 to 
org.apache.brooklyn/brooklyn-locations-jclouds/0.10.0-SNAPSHOT/brooklyn-locations-jclouds-0.10.0-SNAPSHOT-tests.jar
[JENKINS] Archiving 
F:\hudson\hudson-slave\workspace\brooklyn-master-windows\brooklyn-server\locations\jclouds\target\brooklyn-locations-jclouds-0.10.0-SNAPSHOT-sources.jar
 to 
org.apache.brooklyn/brooklyn-locations-jclouds/0.10.0-SNAPSHOT/brooklyn-locations-jclouds-0.10.0-SNAPSHOT-sources.jar
[JENKINS] Archiving 
F:\hudson\hudson-slave\workspace\brooklyn-master-windows\brooklyn-server\locations\jclouds\target\brooklyn-locations-jclouds-0.10.0-SNAPSHOT-test-sources.jar
 to 
org.apache.brooklyn/brooklyn-locations-jclouds/0.10.0-SNAPSHOT/brooklyn-locations-jclouds-0.10.0-SNAPSHOT-test-sources.jar
No artifacts from brooklyn-master-windows » Brooklyn Jclouds Location Targets 
#100 to compare, so performing full copy of artifacts
[JENKINS] Archiving 
F:\hudson\hudson-slave\workspace\brooklyn-master-windows\brooklyn-dist\downstream-parent\pom.xml
 to 
org.apache.brooklyn/brooklyn-downstream-parent/0.10.0-SNAPSHOT/brooklyn-downstream-parent-0.10.0-SNAPSHOT.pom
[JENKINS] Archiving 
F:\hudson\hudson-slave\workspace\brooklyn-master-windows\brooklyn-library\software\database\pom.xml
 to 

Re: YAML blueprint: install package utility

2016-05-06 Thread Duncan Grant
I agree that this is a problem that needs solved but I have misgivings
about each of the proposed solutions.

Firstly I think that "discovering" how to write brooklyn yaml can be
difficult.  It can be difficult to find things in the documentation and if
you don't know to look for them in the first place then your only hope is
coming across an example.

So if we pre-install a set of bash scripts before running the install
scripts I don't see any obvious way for someone using brooklyn to find out
about those scripts, and when the scripts change I imagine people won't
notice the new functionality either.
Another downside to using scripts is that it will become more difficult to
debug script failures.  At the moment I can copy the contents of stdin and
see the error associated.  If I had to step into scripts in other files it
could become much harder to find a failure.  In my opinion this ease of
reproducibility and seeing the code I am running is one of the advantages
of using bash over just using chef/puppet/salt/etc.
If we could find a widely used, well tested bash library then some of these
issues might be mitigated but I've yet to find one.

There is a similar issue with discovering the behaviour of the DSL option.
I think that the DSL only works because we keep it to a minimum and really
it only does one task - which is run-time configuring relationships between
entities.  If we extend it then we have replaced java with dsl and I don't
think that benefits anyone.  One advantage of the DSL option is that it
will generate bash so it shouldn't make debugging any harder.

The advantage of adding config options to the VanillaSoftwareProcess is
that it adds to extra ways of discovering the behaviour - through the
composer's autocomplete and in javadoc.  I assume that this would generate
extra tasks so we could again debug the bash used and it might make it
easier as we might be able to see exactly which package failed to install.
However the big downside to this is that we are starting to make a sort of
god object which contains all brooklyn functionality in one object - i.e.
VanilllaSoftwareProcess and I'm not sure that's where we want to go.

After all that I don't really have a good answer.

My not too good answer would be to make more use of the brooklyn child
relationship so that a) at least the yaml could be composed from small
pieces of code b) we could write a InstallPackage entity to simplify the
yaml.

This might look something like:

- type: brooklyn.entity.basic.VanillaSoftwareProcess
  install.command: curl somefile > somfile.txt
  brooklyn.config:
children.startable.mode: foreground_early
  brooklyn.children:
  - type: brooklyn.entity.basic.VanillaSoftwareProcess
install.command: |
which curl || \
{ sudo apt-get update && sudo apt-get install curl ; } || \
{ sudo yum update && sudo yum install curl ; } || \
{ echo WARNING: cannot install curl && exit 1 ; }
or
  - type: brooklyn.entity.basic.InstallPackage
package: curl
or
  - type: brooklyn.entity.basic.InstallPackage
packages:
  yum: curl
  apt: someOtherCurl

This way everything is discoverable through documentation, javadoc, and
autocomplete.  Common requirements like curl are re-usable. Generated bash
is explicit and if curl fails then it will go on fire.
On the other hand it requires longer yaml, isn't as readable, and due to
the use of child parent relationships has a bit of a learning hurdle

Regards

Duncan


On Wed, 4 May 2016 at 17:35 Thomas Bouron 
wrote:

> Hi Guglielmo.
>
> I'm not sure to follow your idea of "stacks", could you elaborate on that
> please?
>
> Best.
>
> On Tue, 3 May 2016, 13:38 Guglielmo Nigri, <
> guglielmo.ni...@cloudsoftcorp.com> wrote:
>
> > I propose a declarative approach. For example we could add a configKey to
> > VanillaSoftwareProcess called requiredPackages.
> >
> > This way, one could just specify the prerequisite packages, sort of
> > dependencies for the software process -- this would also open up
> > interesting possibilities such as “stacks” as bundled dependencies.
> >
> > A declarative approach would also work for Windows (or non-bash
> > environments).
> >
> > Cheers,
> > Guglielmo
> >
> >
> > On 3 May 2016 at 14:28, Andrea Turli 
> > wrote:
> >
> > > Great discussion guys!
> > >
> > > It seems that it is a shared need, and I wanted to discuss with you as
> I
> > > was not sure about my approach.
> > >
> > > Andrew,
> > >
> > > I like your proposal, thanks!
> > >
> > > Thanks,
> > > Andrea
> > >
> > >
> > > On 3 May 2016 at 13:05, Aled Sage  wrote:
> > >
> > > > I lean towards Andrew's approach, rather than a special
> > > > $brooklyn.installPackage. Note that different distros use different
> > > package
> > > > names sometimes, so the parameters to such a function can get
> annoying.
> > > >
> > > > I've been hesitant about us going down the 

[jira] [Created] (BROOKLYN-265) Slow connection to remote Brooklyn allows Deploy button to be clicked multiple times

2016-05-06 Thread John McCabe (JIRA)
John McCabe created BROOKLYN-265:


 Summary: Slow connection to remote Brooklyn allows Deploy button 
to be clicked multiple times
 Key: BROOKLYN-265
 URL: https://issues.apache.org/jira/browse/BROOKLYN-265
 Project: Brooklyn
  Issue Type: Bug
Reporter: John McCabe
Priority: Minor


I was connected via a slow network connection to a remote Brooklyn instance and 
when I first clicked deploy it seemed as though it hadn't registered so I 
quickly clicked the button again.

The second time I was redirected to the applications page where there were two 
instances of the application being deployed. Ideally this should not result in 
multiple apps being deployed.



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


[GitHub] brooklyn-library pull request: Allow creating roles for PostgreSQL

2016-05-06 Thread geomacy
Github user geomacy commented on a diff in the pull request:

https://github.com/apache/brooklyn-library/pull/33#discussion_r62326206
  
--- Diff: 
software/database/src/main/java/org/apache/brooklyn/entity/database/postgresql/PostgreSqlSshDriver.java
 ---
@@ -328,9 +340,39 @@ private void initializeNewDatabase() {
 " --command="+ createUserCommand),
 sudoAsUser("postgres", getInstallDir() + "/bin/psql -p " + 
entity.getAttribute(PostgreSqlNode.POSTGRESQL_PORT) + 
 " --command="+ createDatabaseCommand),
+createRolesAdditionalCommand,
 callPgctl("stop", true))
 .failOnNonZeroResultCode().execute();
 }
+
+private String buildCreateRolesQuery() {
+Map roles = entity.getConfig(PostgreSqlNode.ROLES);
+String createRolesQuery = "\"";
+
+for (Map.Entry role: roles.entrySet()) {
+createRolesQuery = 
createRolesQuery.concat(String.format("CREATE ROLE %s", role.getKey()));
--- End diff --

@duncangrant you're right, if you can add arbitrary instructions in a 
script there's no point in worrying about injection  - my original comment 
didn't take that into account, it was just a gut reaction to seeing constructed 
SQL text.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Updated] (BROOKLYN-264) Stop app while VM still being provisioned: vm is left running when app is expunged

2016-05-06 Thread Aled Sage (JIRA)

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

Aled Sage updated BROOKLYN-264:
---
Description: 
A customer deployed an app to AWS, but while the VM was still starting up they 
stopped (and thus expunged) the app. The app disappeared from the Brooklyn 
web-console, but the starting VM was left behind in AWS.

This is simple to reproduce:
1. deploy a simple blueprint, such as:
{noformat}
location: aws-ec2:us-east-1
services:
- type: org.apache.brooklyn.entity.machine.MachineEntity
{noformat}
2. wait for the VM to appear in the AWS web-console (with state "initialising")
3. call the {{stop}} effector on the top-level app.

---
Looking at the {{start}} task that was executing at the time when {{stop}} was 
called, below is the thread's stack trace:

{noformat}
Provisioning machine in JcloudsLocation[AWS 
Virginia:/aws-ec2:us-east-1@eyNrLIo5]

Task[provisioning (AWS Virginia)]@MJITkjw0
Submitted by SoftlyPresent[value=Task[start]@tKw0qJET]

In progress, thread waiting (notify) on 
java.util.concurrent.CountDownLatch$Sync@2ed5be36
At: 
org.jclouds.concurrent.FutureIterables.awaitCompletion(FutureIterables.java:149)

org.jclouds.compute.internal.BaseComputeService.createNodesInGroup(BaseComputeService.java:214)

org.jclouds.ec2.compute.EC2ComputeService.createNodesInGroup(EC2ComputeService.java:149)

org.apache.brooklyn.location.jclouds.JcloudsLocation.obtainOnce(JcloudsLocation.java:726)

org.apache.brooklyn.location.jclouds.JcloudsLocation.obtain(JcloudsLocation.java:616)

org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ObtainLocationTask.call(MachineLifecycleEffectorTasks.java:406)

org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ObtainLocationTask.call(MachineLifecycleEffectorTasks.java:396)
org.apache.brooklyn.util.core.task.Tasks.withBlockingDetails(Tasks.java:98)

org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ProvisionMachineTask.call(MachineLifecycleEffectorTasks.java:380)

org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ProvisionMachineTask.call(MachineLifecycleEffectorTasks.java:364)

org.apache.brooklyn.util.core.task.DynamicSequentialTask$DstJob.call(DynamicSequentialTask.java:359)

org.apache.brooklyn.util.core.task.BasicExecutionManager$SubmissionCallable.call(BasicExecutionManager.java:519)
{noformat}

>From this, we can see that we are still calling jclouds. This means that 
>jclouds has not yet returned to Brooklyn the VM's id. It also means that the 
>{{MachineEntity}} will not have been given a {{JcloudsSshMachineLocation}} 
>instance. 

When {{stop}} is called on the {{MachineEntity}}, it doesn't have a machine 
location instance so it doesn't have anything to ask to stop. This is why the 
VM is left running.


  was:
A customer deployed an app to AWS, but while the VM was still starting up they 
stopped (and thus expunged) the app. The app disappeared from the Brooklyn 
web-console, but the starting VM was left behind in AWS.

This is simple to reproduce:
1. deploy a simple blueprint, such as:
{noformat}
location: aws-ec2:us-east-1
services:
- type: org.apache.brooklyn.entity.machine.MachineEntity
{noformat}
2. wait for the VM to appear in the AWS web-console (with state "initialising")
3. call the {{stop}} effector on the top-level app.

---
Looking at the {{start}} task that was executing at the time when {{stop}} was 
called, below is the thread's stack trace:

```
Provisioning machine in JcloudsLocation[AWS 
Virginia:/aws-ec2:us-east-1@eyNrLIo5]

Task[provisioning (AWS Virginia)]@MJITkjw0
Submitted by SoftlyPresent[value=Task[start]@tKw0qJET]

In progress, thread waiting (notify) on 
java.util.concurrent.CountDownLatch$Sync@2ed5be36
At: 
org.jclouds.concurrent.FutureIterables.awaitCompletion(FutureIterables.java:149)

org.jclouds.compute.internal.BaseComputeService.createNodesInGroup(BaseComputeService.java:214)

org.jclouds.ec2.compute.EC2ComputeService.createNodesInGroup(EC2ComputeService.java:149)

org.apache.brooklyn.location.jclouds.JcloudsLocation.obtainOnce(JcloudsLocation.java:726)

org.apache.brooklyn.location.jclouds.JcloudsLocation.obtain(JcloudsLocation.java:616)

org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ObtainLocationTask.call(MachineLifecycleEffectorTasks.java:406)

org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ObtainLocationTask.call(MachineLifecycleEffectorTasks.java:396)
org.apache.brooklyn.util.core.task.Tasks.withBlockingDetails(Tasks.java:98)

org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ProvisionMachineTask.call(MachineLifecycleEffectorTasks.java:380)


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

2016-05-06 Thread Alex Heneveld


Mike, All-

Rather than move the YAML into Java how about working towards being able 
to import YAML fragments?


In the simplest case this could be something like

brooklyn.enrichers:
- $brooklyn:import(cluster-list-member-addresses-enrichers.yaml)
- ... # another enricher

Where your pair of enrichers are simply saved in another file which you 
can reuse.  This practical only if we can upload a ZIP file which 
contains both our BOM and the YAML it references -- but that feels 
extremely valuable and straightforward once we have OSGi.  We could use 
it for scripts and images also.  And we could use OSGi dependencies so 
for instance "cluster-list...yaml" might be in a bundle called 
"mikes-handy-brooklyn-fragments", and then in my BOM i just declare your 
bundle as a library i need and then i can import the yaml (without 
needing my own copy).


We'd need to think through the semantics of importing but it's natural 
if importing a list into a list automatically flattens one level.  (So 
your aggregator and joiner end up as the first two entries in 
"brooklyn.enrichers",  not having the first entry in that list being 
another list which comes from the imported yaml).


We'd probably also want the ability to customize what we reference.  
Freemarker templates might be the simplest way:


  - $brooklyn:import_template:
url: cluster-list-member-addresses-enrichers.yaml
template_variables:
output_list_sensor_name:  member.host.address.list
output_string_sensor_name: 
member.host.address.list.comma_separated


An alternative to templates would be to have some way of doing deep 
merges to overwrite specific fields -- which is tempting but in my 
explorations that always gets hairy, eg when you want to remove 
something, or when lists are involved.


Another approach is to have a "brooklyn.mixins" section as part of the 
entity spec yaml, allowing you for instance to combine entity specs a la 
multiple inheritance.  So for instance I could define an entity spec 
which just gives those two enrichers.  And then when I want to use it I 
mix in that spec.  This would be also be useful for strong typing, where 
the mixin acts like an interface. So we could have an entity spec 
"Datastore" which defines a sensor "datastore.url".  Then if I write a 
"MyMysql" entity it is of supertype VanillaSoftware but it mixes this 
"Datastore" then defines the feed to populate the sensor.  Elsewhere I 
can say that MyNodeJs requires a "Datastore" type, and MyMysql would be 
eligible.  But I think this would need a lot more thought; importing is 
simpler!


Best
Alex


On 06/05/2016 09:16, Thomas Bouron wrote:

+0.5

I like the idea but I'm afraid it is too specific (i.e for DynamicClusters
only) whereas enrichers are supposed to be generic.
I would then do something like this:

- You can have this for the generic case:

```
 brooklyn.enrichers:
 - type: org.apache.brooklyn.enricher.stock.ListGenerator
   brooklyn.config:
 uniqueTag: member-address-list-generator
 enricher.sourceSensors:
 - $brooklyn:entity("entity1").sensor("member.host.address")
 - $brooklyn:entity("entity2").sensor("member.host.address")
 - $brooklyn:entity("entity3").sensor("member.host.address")
 enricher.targetSensor: $brooklyn:sensor("member.host.address.list")
```

- Or this for a cluster:

```
 brooklyn.enrichers:
 - type: org.apache.brooklyn.enricher.stock.ListGenerator
   brooklyn.config:
 uniqueTag: member-address-list-generator
 enricher.sourceCluster: $brooklyn:entity("my-cluster")
 enricher.sourceSensor: $brooklyn:sensor("member.host.address")
 enricher.targetSensor: $brooklyn:sensor("member.host.address.list")
```

WDYT?

On Fri, 6 May 2016 at 06:52 David Bush  wrote:


+1

Using this in a couple of blueprints at the moment and would be really
nice to have a concise method.

--
David Bush • Systems Integrator • Cloudsoft Corporation •
http://www.cloudsoftcorp.com 
T: 07834 127195 • SKYPE: david.c.bush


On 6 May 2016, at 01:44, Mike Zaccardo 

wrote:

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

[GitHub] brooklyn-server pull request: Make entity ids lowercase

2016-05-06 Thread grkvlt
GitHub user grkvlt opened a pull request:

https://github.com/apache/brooklyn-server/pull/134

Make entity ids lowercase

Needed to allow use of entity and application ids as part of DNS names, 
which
are case-insensitive. Extension to 10 characters gives equivalent amount of
randomness, so collision probability is unchanged.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/grkvlt/brooklyn-server lowercase-entity-ids

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/brooklyn-server/pull/134.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #134


commit 20ec1b136c7993868ae341713ba71d87fcd62499
Author: Andrew Donald Kennedy 
Date:   2016-05-06T09:57:06Z

Make entity ids lowercase

Needed to allow use of entity and application ids as part of DNS names, 
which
are case-insensitive. Extension to 10 characters gives equivalent amount of
randomness, so collision probability is unchanged.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] brooklyn-docs pull request: Update the tests documentation

2016-05-06 Thread tbouron
GitHub user tbouron opened a pull request:

https://github.com/apache/brooklyn-docs/pull/55

Update the tests documentation

It explicitly says that the target for a test can be omitted if wrapped 
into a TestCase that already defines the target.

Here is how it looks like:

![test-entities](https://cloud.githubusercontent.com/assets/2082759/15069394/3292dfea-1375-11e6-8a72-dc24992d0d97.png)


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/tbouron/brooklyn-docs fix/test-docs

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/brooklyn-docs/pull/55.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #55


commit e32ae081735057b658b042ebf67e134e32d6ef82
Author: Thomas Bouron 
Date:   2016-05-06T09:23:09Z

Update the tests documentation to explicitly say that the target can be 
omitted if wrapped into a TestCase that already defines the target




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] brooklyn-library pull request: Allow creating roles for PostgreSQL

2016-05-06 Thread duncangrant
Github user duncangrant commented on a diff in the pull request:

https://github.com/apache/brooklyn-library/pull/33#discussion_r62303117
  
--- Diff: 
software/database/src/main/java/org/apache/brooklyn/entity/database/postgresql/PostgreSqlSshDriver.java
 ---
@@ -328,9 +340,39 @@ private void initializeNewDatabase() {
 " --command="+ createUserCommand),
 sudoAsUser("postgres", getInstallDir() + "/bin/psql -p " + 
entity.getAttribute(PostgreSqlNode.POSTGRESQL_PORT) + 
 " --command="+ createDatabaseCommand),
+createRolesAdditionalCommand,
 callPgctl("stop", true))
 .failOnNonZeroResultCode().execute();
 }
+
+private String buildCreateRolesQuery() {
+Map roles = entity.getConfig(PostgreSqlNode.ROLES);
+String createRolesQuery = "\"";
+
+for (Map.Entry role: roles.entrySet()) {
+createRolesQuery = 
createRolesQuery.concat(String.format("CREATE ROLE %s", role.getKey()));
--- End diff --

Sorry - I meant I don't see the relevance of protecting against sql 
injection.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] brooklyn-library pull request: Allow creating roles for PostgreSQL

2016-05-06 Thread tbouron
Github user tbouron commented on a diff in the pull request:

https://github.com/apache/brooklyn-library/pull/33#discussion_r62302857
  
--- Diff: 
software/database/src/main/java/org/apache/brooklyn/entity/database/postgresql/PostgreSqlSshDriver.java
 ---
@@ -328,9 +340,39 @@ private void initializeNewDatabase() {
 " --command="+ createUserCommand),
 sudoAsUser("postgres", getInstallDir() + "/bin/psql -p " + 
entity.getAttribute(PostgreSqlNode.POSTGRESQL_PORT) + 
 " --command="+ createDatabaseCommand),
+createRolesAdditionalCommand,
 callPgctl("stop", true))
 .failOnNonZeroResultCode().execute();
 }
+
+private String buildCreateRolesQuery() {
+Map roles = entity.getConfig(PostgreSqlNode.ROLES);
+String createRolesQuery = "\"";
+
+for (Map.Entry role: roles.entrySet()) {
+createRolesQuery = 
createRolesQuery.concat(String.format("CREATE ROLE %s", role.getKey()));
--- End diff --

Ease of use I guess? Also, you could imagine to call this from an effector 
to create users and roles on the fly


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] brooklyn-library pull request: Allow creating roles for PostgreSQL

2016-05-06 Thread duncangrant
Github user duncangrant commented on a diff in the pull request:

https://github.com/apache/brooklyn-library/pull/33#discussion_r62302094
  
--- Diff: 
software/database/src/main/java/org/apache/brooklyn/entity/database/postgresql/PostgreSqlSshDriver.java
 ---
@@ -328,9 +340,39 @@ private void initializeNewDatabase() {
 " --command="+ createUserCommand),
 sudoAsUser("postgres", getInstallDir() + "/bin/psql -p " + 
entity.getAttribute(PostgreSqlNode.POSTGRESQL_PORT) + 
 " --command="+ createDatabaseCommand),
+createRolesAdditionalCommand,
 callPgctl("stop", true))
 .failOnNonZeroResultCode().execute();
 }
+
+private String buildCreateRolesQuery() {
+Map roles = entity.getConfig(PostgreSqlNode.ROLES);
+String createRolesQuery = "\"";
+
+for (Map.Entry role: roles.entrySet()) {
+createRolesQuery = 
createRolesQuery.concat(String.format("CREATE ROLE %s", role.getKey()));
--- End diff --

I don't see the relevance.  This is a command populated from a blueprint 
where you can also add an database initialisation script that can do whatever 
you want.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


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

2016-05-06 Thread Thomas Bouron
+0.5

I like the idea but I'm afraid it is too specific (i.e for DynamicClusters
only) whereas enrichers are supposed to be generic.
I would then do something like this:

   - You can have this for the generic case:

```
brooklyn.enrichers:
- type: org.apache.brooklyn.enricher.stock.ListGenerator
  brooklyn.config:
uniqueTag: member-address-list-generator
enricher.sourceSensors:
- $brooklyn:entity("entity1").sensor("member.host.address")
- $brooklyn:entity("entity2").sensor("member.host.address")
- $brooklyn:entity("entity3").sensor("member.host.address")
enricher.targetSensor: $brooklyn:sensor("member.host.address.list")
```

   - Or this for a cluster:

```
brooklyn.enrichers:
- type: org.apache.brooklyn.enricher.stock.ListGenerator
  brooklyn.config:
uniqueTag: member-address-list-generator
enricher.sourceCluster: $brooklyn:entity("my-cluster")
enricher.sourceSensor: $brooklyn:sensor("member.host.address")
enricher.targetSensor: $brooklyn:sensor("member.host.address.list")
```

WDYT?

On Fri, 6 May 2016 at 06:52 David Bush  wrote:

> +1
>
> Using this in a couple of blueprints at the moment and would be really
> nice to have a concise method.
>
> --
> David Bush • Systems Integrator • Cloudsoft Corporation •
> http://www.cloudsoftcorp.com 
> T: 07834 127195 • SKYPE: david.c.bush
>
> > On 6 May 2016, at 01:44, Mike Zaccardo 
> wrote:
> >
> > 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
>
> --
Thomas Bouron • Software Engineer @ Cloudsoft Corporation •
http://www.cloudsoftcorp.com/
Github: https://github.com/tbouron
Twitter: https://twitter.com/eltibouron


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

2016-05-06 Thread Geoff Macartney
+1 looks like an excellent suggestion to me



Gnu PGP key - http://is.gd/uI


> On 6 May 2016, at 01:44, Mike Zaccardo  
> wrote:
> 
> 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



[GitHub] brooklyn-library pull request: Allow creating roles for PostgreSQL

2016-05-06 Thread geomacy
Github user geomacy commented on a diff in the pull request:

https://github.com/apache/brooklyn-library/pull/33#discussion_r62298938
  
--- Diff: 
software/database/src/main/java/org/apache/brooklyn/entity/database/postgresql/PostgreSqlSshDriver.java
 ---
@@ -328,9 +340,39 @@ private void initializeNewDatabase() {
 " --command="+ createUserCommand),
 sudoAsUser("postgres", getInstallDir() + "/bin/psql -p " + 
entity.getAttribute(PostgreSqlNode.POSTGRESQL_PORT) + 
 " --command="+ createDatabaseCommand),
+createRolesAdditionalCommand,
 callPgctl("stop", true))
 .failOnNonZeroResultCode().execute();
 }
+
+private String buildCreateRolesQuery() {
+Map roles = entity.getConfig(PostgreSqlNode.ROLES);
+String createRolesQuery = "\"";
+
+for (Map.Entry role: roles.entrySet()) {
+createRolesQuery = 
createRolesQuery.concat(String.format("CREATE ROLE %s", role.getKey()));
--- End diff --

Actually I'm not sure you're going to be able to use prepared statements 
with DDL like CREATE ROLE, at least not with Postgres.  (Worth a look to see 
whether it's supported anyway.)  At the very least, as Thomas says, you should 
be validating the input before using it in a statement.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[GitHub] brooklyn-library pull request: Allow creating roles for PostgreSQL

2016-05-06 Thread tbouron
Github user tbouron commented on a diff in the pull request:

https://github.com/apache/brooklyn-library/pull/33#discussion_r62295255
  
--- Diff: 
software/database/src/main/java/org/apache/brooklyn/entity/database/postgresql/PostgreSqlSshDriver.java
 ---
@@ -328,9 +340,39 @@ private void initializeNewDatabase() {
 " --command="+ createUserCommand),
 sudoAsUser("postgres", getInstallDir() + "/bin/psql -p " + 
entity.getAttribute(PostgreSqlNode.POSTGRESQL_PORT) + 
 " --command="+ createDatabaseCommand),
+createRolesAdditionalCommand,
 callPgctl("stop", true))
 .failOnNonZeroResultCode().execute();
 }
+
+private String buildCreateRolesQuery() {
+Map roles = entity.getConfig(PostgreSqlNode.ROLES);
+String createRolesQuery = "\"";
+
+for (Map.Entry role: roles.entrySet()) {
+createRolesQuery = 
createRolesQuery.concat(String.format("CREATE ROLE %s", role.getKey()));
--- End diff --

+1, always validate and escape input from the user, especially for SQL 
queries.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---