Build failed in Jenkins: incubator-brooklyn-master-build #744

[Apache Jenkins Server]

See 

Changes:

[duncan.godwin] Getting Started with Vagrant updates - for review

[duncan.godwin] Adding Vagrant Temp URL

[duncan.godwin] Updated blueprints + fixes

[duncan.godwin] Updated blueprints and managing

[duncan.godwin] Updated blueprints and managing

[duncan.godwin] Fixed stray end tag

[alex.heneveld] ensure install-label-salt-inferencing does not block

[alex.heneveld] allow spec parameters to imply sensors as well as config keys; 
mainly

[alex.heneveld] support dynamic cluster restart

[alex.heneveld] add more examples to `netcat` illustration, showing port 
inference,

[alex.heneveld] start fleshing out release notes, including reference to the new

[duncan.grant] Create Password Sensor

[john] update make-release-artifacts to work with current repo structure

[john] add apache-brooklyn-VER-vagrant release artifact

[john] update release process docs for current repo structure

[john] add getting started vagrant env to release artifacts - following

[john] correct artifact staging dir path

[alex.heneveld] revert generics change as it causes inconsistent failures in 
different

[duncan.godwin] Concertina in managing, glossary & refactored names

[john] load locations from catalog, strip unnecessary properties -

[john] fix RAT violations

[john] add -SNAPSHOT handling - aborts starting brooklyn VM with a warning and

[john] add README.md to rat excludes

[duncan.godwin] Finished Managing

[duncan.godwin] Updated license for Glossarizer MIT statement

[valentin.aitken] Update storm dependency

[john] add support for SNAPSHOT downloads - supports release downloads via

[duncan.grant] Changes re code review

[alex.heneveld] fix failing (time sensitive) test

[alex.heneveld] fix the nondet cancellation test race observed previously

[alex.heneveld] update license generation to put a file in each project root

[alex.heneveld] update LICENSE files throughout

--
[...truncated 29625 lines...]
[INFO] Exclude: **/.settings/**
[INFO] Exclude: **/*.log
[INFO] Exclude: **/brooklyn*.log.*
[INFO] Exclude: **/target/**
[INFO] Exclude: ignored/**
[INFO] Exclude: LICENSE.md
[INFO] Exclude: **/src/main/license/**
[INFO] Exclude: **/src/test/license/**
[INFO] Exclude: **/MANIFEST.MF
[INFO] Exclude: **/test-output/**
[INFO] Exclude: **/*.pem.pub
[INFO] Exclude: **/*.pem
[INFO] Exclude: **/*_rsa.pub
[INFO] Exclude: **/*_rsa
[INFO] Exclude: **/*.svg
[INFO] Exclude: **/*.crt
[INFO] Exclude: **/*.csr
[INFO] Exclude: **/*.key
[INFO] Exclude: **/*.key.org
[INFO] Exclude: **/*.psd
[INFO] Exclude: **/*.json
[INFO] Exclude: **/*.plxarc
[INFO] Exclude: 
**/src/test/resources/org/apache/brooklyn/entity/software/base/template_with_extra_substitutions.txt
[INFO] Exclude: **/src/main/resources/banner.txt
[INFO] Exclude: **/src/test/resources/ssl/certs/localhost/info.txt
[INFO] Exclude: **/src/main/history/dependencies.xml
[INFO] Exclude: **/sandbox/examples/src/main/scripts/amis.txt
[INFO] Exclude: docs/**
[INFO] 146 resources included (use -debug for more details)
[INFO] Rat check: Summary of files. Unapproved: 1 unknown: 1 generated: 0 
approved: 145 licence.
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Brooklyn REST JavaScript Web GUI .. SUCCESS [42.809s]
[INFO] Brooklyn Server Root .. SUCCESS [0.436s]
[INFO] Brooklyn Parent Project ... SUCCESS [3.444s]
[INFO] Brooklyn Test Support Utilities ... SUCCESS [6.741s]
[INFO] Brooklyn Logback Includable Configuration . SUCCESS [2.168s]
[INFO] Brooklyn Common Utilities . SUCCESS [18.094s]
[INFO] Brooklyn API .. SUCCESS [3.306s]
[INFO] CAMP Server Parent Project  SUCCESS [0.932s]
[INFO] CAMP Base . SUCCESS [4.371s]
[INFO] Brooklyn Test Support . SUCCESS [2.961s]
[INFO] Brooklyn REST Swagger Apidoc Utilities  SUCCESS [17.074s]
[INFO] Brooklyn Logback Configuration  SUCCESS [1.785s]
[INFO] CAMP Server ... SUCCESS [7.634s]
[INFO] Brooklyn OSGi Utils ... SUCCESS [4.065s]
[INFO] Brooklyn Felix Runtime  SUCCESS [4.335s]
[INFO] Brooklyn Groovy Utilities . SUCCESS [2.245s]
[INFO] Brooklyn Core . SUCCESS [3:12.916s]
[INFO] Brooklyn Policies . SUCCESS [1:13.764s]
[INFO] Brooklyn WinRM Software Entities .. SUCCESS [7.685s]
[INFO] Brooklyn Secure JMXMP Agent ... SUCCESS [12.072s]
[INFO] Brooklyn JMX RMI Agent  SUCCESS [1.943s]
[INFO] Brooklyn Jclouds Location Targets . SUC

[GitHub] incubator-brooklyn pull request: Port parameters docs and fixes

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-brooklyn/pull/1166


---
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] incubator-brooklyn pull request: Create Password Sensor

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-brooklyn/pull/1169


---
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] incubator-brooklyn pull request: Uses externally accessible addres...

[ahgittin]

Github user ahgittin commented on the pull request:


https://github.com/apache/incubator-brooklyn/pull/1168#issuecomment-177060034
  
@nakomis could you spearhead the others incl @sjcorbett @aledsage @grkvlt 
to determine what we want to do wrt public/private?

i don't think we can merge this until we've got some guidelines.


---
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] incubator-brooklyn pull request: Uses externally accessible addres...

[ahgittin]

Github user ahgittin commented on the pull request:


https://github.com/apache/incubator-brooklyn/pull/1168#issuecomment-177059968
  
ugly failure this time.  not one i've come across.  probably nondet.  
@nakomix you're not having luck!

```
org.apache.brooklyn.AssemblyTest.checkBrooklynCoreFeature

Failing for the past 1 build (Since Unstable#2472 )
Took 5.5 sec.
Error Message

gave up waiting for service org.apache.karaf.features.BootFinished
Stacktrace

org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for 
service org.apache.karaf.features.BootFinished
at 
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:199)
at 
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:136)
at 
org.ops4j.pax.exam.inject.internal.ServiceInjector.injectField(ServiceInjector.java:89)
at 
org.ops4j.pax.exam.inject.internal.ServiceInjector.injectDeclaredFields(ServiceInjector.java:69)
at 
org.ops4j.pax.exam.inject.internal.ServiceInjector.injectFields(ServiceInjector.java:61)
at 
org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.createTest(ContainerTestRunner.java:61)
at 
org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4ClassRunner.java:266)
```


---
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] incubator-brooklyn pull request: Port parameters docs and fixes

[ahgittin]

Github user ahgittin commented on the pull request:


https://github.com/apache/incubator-brooklyn/pull/1166#issuecomment-177059815
  
merging

@shartzel i'd like you to have a look at this -- feels like a few more 
things like this (examples and ease-of-use tweaks) in the right places would 
make brooklyn much easier to get started with


---
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] incubator-brooklyn pull request: Update storm remove redundant dep...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-brooklyn/pull/1175


---
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] incubator-brooklyn pull request: fix failing (time sensitive) test

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-brooklyn/pull/1178


---
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] incubator-brooklyn pull request: fix the nondet cancellation test ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-brooklyn/pull/1179


---
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] incubator-brooklyn pull request: add getting started vagrant env t...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-brooklyn/pull/1170


---
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] incubator-brooklyn pull request: Getting Started with Vagrant upda...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-brooklyn/pull/1144


---
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] incubator-brooklyn pull request: Getting Started with Vagrant upda...

[ahgittin]

Github user ahgittin commented on the pull request:


https://github.com/apache/incubator-brooklyn/pull/1144#issuecomment-177058516
  
like the concertina.  would be nice if i could click anywhere in the title 
bar, not just on text.

not sure about the glossary.  cute at first but obnoxious after a while.  :)

i'll overwrite the license when i merge, and store the info you provided 
somewhere handy (new `_licensing/` folder in docs)

overall great stuff -- merging


---
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] incubator-brooklyn pull request: Fix/deferred location config

[ahgittin]

Github user ahgittin commented on the pull request:


https://github.com/apache/incubator-brooklyn/pull/1093#issuecomment-177053294
  
@alasdairhodge ping


---
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] incubator-brooklyn pull request: fix the nondet cancellation test ...

[ahgittin]

Github user ahgittin commented on the pull request:


https://github.com/apache/incubator-brooklyn/pull/1179#issuecomment-177052693
  
CTR as this is simple test-only and it's interfering with other PRs.  

@aledsage this is one i'd really like you to be aware of, it's quite subtle 
and quite possibly could bite us elsewhere


---
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] incubator-brooklyn pull request: fix the nondet cancellation test ...

[ahgittin]

GitHub user ahgittin opened a pull request:

https://github.com/apache/incubator-brooklyn/pull/1179

fix the nondet cancellation test race observed previously

the "fix" in #1171 didn't do everything, but provided enough clues to see 
the other culprit which this fixes, i think

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

$ git pull https://github.com/ahgittin/incubator-brooklyn cancel-test-race

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

https://github.com/apache/incubator-brooklyn/pull/1179.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 #1179


commit 627aaad9536b3c81700cf8bfb9135a065bcff220
Author: Alex Heneveld 
Date:   2016-01-30T02:45:09Z

fix the nondet cancellation test race observed previously




---
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] incubator-brooklyn pull request: add getting started vagrant env t...

[ahgittin]

Github user ahgittin commented on the pull request:


https://github.com/apache/incubator-brooklyn/pull/1170#issuecomment-177050161
  
great stuff.  may need more review /cc @drigodwin @aledsage but i'm going 
to merge so it doesn't have to be ported to new repos


---
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] incubator-brooklyn pull request: fix failing (time sensitive) test

[ahgittin]

Github user ahgittin commented on the pull request:


https://github.com/apache/incubator-brooklyn/pull/1178#issuecomment-177048278
  
seems to fix nondet test and checks pass so i'm going to merge; @aledsage 
or @geomacy (since you did a lot of the work on `Asserts`) could you review 
after my commit pls?


---
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] incubator-brooklyn pull request: fix failing (time sensitive) test

[ahgittin]

GitHub user ahgittin opened a pull request:

https://github.com/apache/incubator-brooklyn/pull/1178

fix failing (time sensitive) test

solves the nondet test failure observed in #1176 .

and improve the "Asserts.eventually" routines which that used,
adding a new simpler eventuallyOnNotify(...) and having it used elsewhere.

also add convenience methods for CountdownTimer so its usage is more 
readable.


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

$ git pull https://github.com/ahgittin/incubator-brooklyn 
tidy-timings-and-fix-nondet-test

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

https://github.com/apache/incubator-brooklyn/pull/1178.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 #1178


commit dc0ca058d848e1231cf4c05a603b8a74fd179903
Author: Alex Heneveld 
Date:   2016-01-29T23:30:07Z

fix failing (time sensitive) test

and improve the "Asserts.eventually" routines which that used,
adding a new simpler eventuallyOnNotify(...) and having it used elsewhere.

also add convenience methods for CountdownTimer so its usage is more 
readable.




---
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] incubator-brooklyn pull request: Generate config/effector descript...

[ahgittin]

Github user ahgittin commented on the pull request:


https://github.com/apache/incubator-brooklyn/pull/1176#issuecomment-177017397
  
(easily fixed - the test was doing an immediate assert on something 
happening in another thread; PR to follow; @iyovcheva give it an hour or so for 
the other fix to land then please close+reopen this to run the jenkins tests 
again)


---
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] incubator-brooklyn pull request: Generate config/effector descript...

[ahgittin]

Github user ahgittin commented on the pull request:


https://github.com/apache/incubator-brooklyn/pull/1176#issuecomment-176947214
  
test failure is clearly unrelated, maybe close and reopen to run again.

meanwhile we should look at this /cc @aledsage :

```

org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest.testResizeDirectly
 (from TestSuite)

java.lang.AssertionError: removed=[EmptySoftwareProcessImpl{id=NhzxGta6}] 
expected [2] but found [1]
at org.testng.Assert.fail(Assert.java:94)
at org.testng.Assert.failNotEquals(Assert.java:494)
at org.testng.Assert.assertEquals(Assert.java:123)
at org.testng.Assert.assertEquals(Assert.java:370)
at 
org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest.assertSize(AutoScalerPolicyNoMoreMachinesTest.java:182)
at 
org.apache.brooklyn.entity.software.base.test.autoscaling.AutoScalerPolicyNoMoreMachinesTest.testResizeDirectly(AutoScalerPolicyNoMoreMachinesTest.java:105)
```


---
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] incubator-brooklyn pull request: Improvements to brooklyn-server/r...

[ahgittin]

Github user ahgittin commented on the pull request:


https://github.com/apache/incubator-brooklyn/pull/1177#issuecomment-176945957
  
strange test failure.  can't tell if it is related to this or a new 
intermittent one.


---
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] incubator-brooklyn pull request: Improvements to brooklyn-server/r...

[ahgittin]

Github user ahgittin commented on a diff in the pull request:

https://github.com/apache/incubator-brooklyn/pull/1177#discussion_r51308146
  
--- Diff: 
brooklyn-server/rest/rest-server/src/main/java/org/apache/brooklyn/rest/util/json/BrooklynJacksonJsonProvider.java
 ---
@@ -137,25 +136,21 @@ public static ObjectMapper 
newPrivateObjectMapper(ManagementContext mgmt) {
 throw new IllegalStateException("No management context 
available for creating ObjectMapper");
 }
 
-SerializationConfig defaultConfig = new 
ObjectMapper().getSerializationConfig();
-SerializationConfig sc = new SerializationConfig(
-defaultConfig.getClassIntrospector() /* 
ObjectMapper.DEFAULT_INTROSPECTOR */,
-defaultConfig.getAnnotationIntrospector() /* 
ObjectMapper.DEFAULT_ANNOTATION_INTROSPECTOR */,
-new PossiblyStrictPreferringFieldsVisibilityChecker(),
-null, null, TypeFactory.defaultInstance(), null);
-
 ConfigurableSerializerProvider sp = new 
ConfigurableSerializerProvider();
 sp.setUnknownTypeSerializer(new 
ErrorAndToStringUnknownTypeSerializer());
 
-ObjectMapper mapper = new ObjectMapper(null, sp, null, sc, null);
+ObjectMapper mapper = new ObjectMapper();
+mapper.setSerializerProvider(sp);
+mapper.setVisibility(new 
PossiblyStrictPreferringFieldsVisibilityChecker());
+
 SimpleModule mapperModule = new SimpleModule("Brooklyn", new 
Version(0, 0, 0, "ignored"));
 
 new 
BidiSerialization.ManagementContextSerialization(mgmt).install(mapperModule);
 new 
BidiSerialization.EntitySerialization(mgmt).install(mapperModule);
 new 
BidiSerialization.LocationSerialization(mgmt).install(mapperModule);
-mapperModule.addSerializer(new MultimapSerializer());
--- End diff --

awesome


---
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: Brooklyn Daemon Solution

[Aleksandr Vasilev]

Alex,

In this case, I agree that wrapping java command in a service script may be
the best choice.

Best Regards,
Aleksandr Vasilev
DevOps Engineer | Cloudsoft Corporation

On 29 January 2016 at 20:50, Alex Heneveld 
wrote:

>
> Aleksandr,
>
> Is there anyone who needs this level of security?  In my experience a
> service calling a shell script is common, and in the cases where someone
> needs something stronger they can build it. They possibly have custom
> requirements there in any case.  Bear in mind a daemon is going to
> introduce a lot of complexity (many different OS's) so it would need to
> offer major benefits to users or it's just not worth it, in my view.
>
> OTOH hopefully this is being considered as part of putting together RPM's
> and DEB's and Docker images, as part of the Brooklyn build.  In which case
> the sooner we have that the better, because people do want those.  Even
> installing as a service I think is optional.
>
> FWIW Tomcat *suggest* the use of jsvc at [1] but they leave it for users
> to implement.  In practice I mainly see service scripts calling the
> catalina start shell script which uses java -- not jsvc.
>
> Best
> Alex
>
> [1] https://tomcat.apache.org/tomcat-7.0-doc/setup.html
>
>
>
> On 29/01/2016 15:58, Aleksandr Vasilev wrote:
>
>> Regarding the security implications when using a script vs a binary,
>>>
>> could you explain?
>> It's not the difference between binary vs script, it's the different
>> approach at launching the process. In my daemon I make sure child process
>> is detached from the parent and can't get hold of any terminal sessions,
>> so
>> an attacker can't get any additional privileges.
>>
>> with file descriptor redirection, beyond stderr, stdout what are you
>>> considering
>>>
>> here?
>> Nothing more unless any other file descriptors are opened by Brooklyn. The
>> daemon makes sure to close them all.
>>
>> are you intending this to be used outside of init? we'd have the config
>>>
>> set externally to the daemon
>> Not at all, just suggesting it can be used in any type of service script
>>
>> we don't have to wrap a script surely? the init script doesn't have to
>>>
>> call the brooklyn script.
>> Agreed, we can wrap java command, calling Brooklyn's Main class. Again I'm
>> not sure this solution detaches the child process properly.
>>
>>
>> Best Regards,
>> Aleksandr Vasilev
>> DevOps Engineer | Cloudsoft Corporation
>>
>>
>> On 29 January 2016 at 18:45, John McCabe  wrote:
>>
>> Hi Aleksandr,
>>>
>>> 1. Proper detaching from the parent process, making daemon more secure
 2. Proper detaching from any TTYs, making daemon even more secure

>>>   Regarding the security implications when using a script vs a binary,
>>> could
>>> you explain?
>>>
>>> 3. Proper redirection of all file descriptors, helps with debugging and
 logging

>>> with file descriptor redirection, beyond stderr, stdout what are you
>>> considering here?
>>>
>>> 5. More flexible solution: ability to run Brooklyn with any arguments,
 service script will have "brooklyn launch" part hardcoded and will

>>> require
>>>
 to edit the code each time you need to run it with the new args.

>>> are you intending this to be used outside of init? we'd have the config
>>> set
>>> externally to the daemon
>>>
>>> Overall I see the native daemon solution as more traditional and

>>> compliant
>>>
 to Linux standards than just wrapping bash script in yet another script.

>>> we don't have to wrap a script surely? the init script doesn't have to
>>> call
>>> the brooklyn script.
>>>
>>> All the best,
>>> John
>>>
>>> On Fri, Jan 29, 2016 at 2:58 PM, Aleksandr Vasilev <
>>> aleksandr.vasi...@cloudsoftcorp.com> wrote:
>>>
>>> Hi Alex,

 The advantages of having a native daemon in my opinion are:
 1. Proper detaching from the parent process, making daemon more secure
 2. Proper detaching from any TTYs, making daemon even more secure
 3. Proper redirection of all file descriptors, helps with debugging and
 logging
 4. More portable solution, as the daemon can be used in any type of

>>> service
>>>
 scripts or even on its own, not only systemd script
 5. More flexible solution: ability to run Brooklyn with any arguments,
 service script will have "brooklyn launch" part hardcoded and will

>>> require
>>>
 to edit the code each time you need to run it with the new args.

 Overall I see the native daemon solution as more traditional and

>>> compliant
>>>
 to Linux standards than just wrapping bash script in yet another script.

 Best Regards,
 Aleksandr Vasilev
 DevOps Engineer | Cloudsoft Corporation

 On 29 January 2016 at 17:30, John McCabe  wrote:

 [bumping so aleks can see the thread]
>
> On Thu, 28 Jan 2016 at 16:41 Andrew Kennedy <
> andrew.kenn...@cloudsoftcorp.com> wrote:
>
> Or what about running a Brooklyn Docker image as a syste

Re: Brooklyn Daemon Solution

[Alex Heneveld]

Aleksandr,

Is there anyone who needs this level of security?  In my experience a 
service calling a shell script is common, and in the cases where someone 
needs something stronger they can build it. They possibly have custom 
requirements there in any case.  Bear in mind a daemon is going to 
introduce a lot of complexity (many different OS's) so it would need to 
offer major benefits to users or it's just not worth it, in my view.


OTOH hopefully this is being considered as part of putting together 
RPM's and DEB's and Docker images, as part of the Brooklyn build.  In 
which case the sooner we have that the better, because people do want 
those.  Even installing as a service I think is optional.


FWIW Tomcat *suggest* the use of jsvc at [1] but they leave it for users 
to implement.  In practice I mainly see service scripts calling the 
catalina start shell script which uses java -- not jsvc.


Best
Alex

[1] https://tomcat.apache.org/tomcat-7.0-doc/setup.html


On 29/01/2016 15:58, Aleksandr Vasilev wrote:

Regarding the security implications when using a script vs a binary,

could you explain?
It's not the difference between binary vs script, it's the different
approach at launching the process. In my daemon I make sure child process
is detached from the parent and can't get hold of any terminal sessions, so
an attacker can't get any additional privileges.


with file descriptor redirection, beyond stderr, stdout what are you considering

here?
Nothing more unless any other file descriptors are opened by Brooklyn. The
daemon makes sure to close them all.


are you intending this to be used outside of init? we'd have the config

set externally to the daemon
Not at all, just suggesting it can be used in any type of service script


we don't have to wrap a script surely? the init script doesn't have to

call the brooklyn script.
Agreed, we can wrap java command, calling Brooklyn's Main class. Again I'm
not sure this solution detaches the child process properly.


Best Regards,
Aleksandr Vasilev
DevOps Engineer | Cloudsoft Corporation


On 29 January 2016 at 18:45, John McCabe  wrote:


Hi Aleksandr,


1. Proper detaching from the parent process, making daemon more secure
2. Proper detaching from any TTYs, making daemon even more secure

  Regarding the security implications when using a script vs a binary, could
you explain?


3. Proper redirection of all file descriptors, helps with debugging and
logging

with file descriptor redirection, beyond stderr, stdout what are you
considering here?


5. More flexible solution: ability to run Brooklyn with any arguments,
service script will have "brooklyn launch" part hardcoded and will

require

to edit the code each time you need to run it with the new args.

are you intending this to be used outside of init? we'd have the config set
externally to the daemon


Overall I see the native daemon solution as more traditional and

compliant

to Linux standards than just wrapping bash script in yet another script.

we don't have to wrap a script surely? the init script doesn't have to call
the brooklyn script.

All the best,
John

On Fri, Jan 29, 2016 at 2:58 PM, Aleksandr Vasilev <
aleksandr.vasi...@cloudsoftcorp.com> wrote:


Hi Alex,

The advantages of having a native daemon in my opinion are:
1. Proper detaching from the parent process, making daemon more secure
2. Proper detaching from any TTYs, making daemon even more secure
3. Proper redirection of all file descriptors, helps with debugging and
logging
4. More portable solution, as the daemon can be used in any type of

service

scripts or even on its own, not only systemd script
5. More flexible solution: ability to run Brooklyn with any arguments,
service script will have "brooklyn launch" part hardcoded and will

require

to edit the code each time you need to run it with the new args.

Overall I see the native daemon solution as more traditional and

compliant

to Linux standards than just wrapping bash script in yet another script.

Best Regards,
Aleksandr Vasilev
DevOps Engineer | Cloudsoft Corporation

On 29 January 2016 at 17:30, John McCabe  wrote:


[bumping so aleks can see the thread]

On Thu, 28 Jan 2016 at 16:41 Andrew Kennedy <
andrew.kenn...@cloudsoftcorp.com> wrote:


Or what about running a Brooklyn Docker image as a systemd service!

-

http://container-solutions.com/running-docker-containers-with-systemd/

- https://github.com/ibuildthecloud/systemd-docker

Andrew.

On Thu, 28 Jan 2016 at 16:34 Alex Heneveld <
alex.henev...@cloudsoftcorp.com>
wrote:


Hi Aleksandr-

What's the advantage of a native daemon over just wrapping it as a

linux

service script ?

Best
Alex


On 28/01/2016 11:32, Aleksandr Vasilev wrote:

Hello everyone!

I spent last few days looking at the solution to run Brooklyn

process

as

a

daemon and found two options:
1. Run daemon via Apache Commons Daemon (jsvc)
2. Write a custom daemon in C

Both solutions has its own pros and cons, so let's look at what I

think

Re: Brooklyn Daemon Solution

[Aleksandr Vasilev]

> Regarding the security implications when using a script vs a binary,
could you explain?
It's not the difference between binary vs script, it's the different
approach at launching the process. In my daemon I make sure child process
is detached from the parent and can't get hold of any terminal sessions, so
an attacker can't get any additional privileges.

>with file descriptor redirection, beyond stderr, stdout what are you 
>considering
here?
Nothing more unless any other file descriptors are opened by Brooklyn. The
daemon makes sure to close them all.

>are you intending this to be used outside of init? we'd have the config
set externally to the daemon
Not at all, just suggesting it can be used in any type of service script

>we don't have to wrap a script surely? the init script doesn't have to
call the brooklyn script.
Agreed, we can wrap java command, calling Brooklyn's Main class. Again I'm
not sure this solution detaches the child process properly.


Best Regards,
Aleksandr Vasilev
DevOps Engineer | Cloudsoft Corporation


On 29 January 2016 at 18:45, John McCabe  wrote:

> Hi Aleksandr,
>
> > 1. Proper detaching from the parent process, making daemon more secure
> > 2. Proper detaching from any TTYs, making daemon even more secure
>
>  Regarding the security implications when using a script vs a binary, could
> you explain?
>
> > 3. Proper redirection of all file descriptors, helps with debugging and
> > logging
>
> with file descriptor redirection, beyond stderr, stdout what are you
> considering here?
>
> > 5. More flexible solution: ability to run Brooklyn with any arguments,
> > service script will have "brooklyn launch" part hardcoded and will
> require
> > to edit the code each time you need to run it with the new args.
>
> are you intending this to be used outside of init? we'd have the config set
> externally to the daemon
>
> > Overall I see the native daemon solution as more traditional and
> compliant
> > to Linux standards than just wrapping bash script in yet another script.
>
> we don't have to wrap a script surely? the init script doesn't have to call
> the brooklyn script.
>
> All the best,
> John
>
> On Fri, Jan 29, 2016 at 2:58 PM, Aleksandr Vasilev <
> aleksandr.vasi...@cloudsoftcorp.com> wrote:
>
> > Hi Alex,
> >
> > The advantages of having a native daemon in my opinion are:
> > 1. Proper detaching from the parent process, making daemon more secure
> > 2. Proper detaching from any TTYs, making daemon even more secure
> > 3. Proper redirection of all file descriptors, helps with debugging and
> > logging
> > 4. More portable solution, as the daemon can be used in any type of
> service
> > scripts or even on its own, not only systemd script
> > 5. More flexible solution: ability to run Brooklyn with any arguments,
> > service script will have "brooklyn launch" part hardcoded and will
> require
> > to edit the code each time you need to run it with the new args.
> >
> > Overall I see the native daemon solution as more traditional and
> compliant
> > to Linux standards than just wrapping bash script in yet another script.
> >
> > Best Regards,
> > Aleksandr Vasilev
> > DevOps Engineer | Cloudsoft Corporation
> >
> > On 29 January 2016 at 17:30, John McCabe  wrote:
> >
> > > [bumping so aleks can see the thread]
> > >
> > > On Thu, 28 Jan 2016 at 16:41 Andrew Kennedy <
> > > andrew.kenn...@cloudsoftcorp.com> wrote:
> > >
> > > > Or what about running a Brooklyn Docker image as a systemd service!
> > > >
> > > > -
> > http://container-solutions.com/running-docker-containers-with-systemd/
> > > > - https://github.com/ibuildthecloud/systemd-docker
> > > >
> > > > Andrew.
> > > >
> > > > On Thu, 28 Jan 2016 at 16:34 Alex Heneveld <
> > > > alex.henev...@cloudsoftcorp.com>
> > > > wrote:
> > > >
> > > > >
> > > > > Hi Aleksandr-
> > > > >
> > > > > What's the advantage of a native daemon over just wrapping it as a
> > > linux
> > > > > service script ?
> > > > >
> > > > > Best
> > > > > Alex
> > > > >
> > > > >
> > > > > On 28/01/2016 11:32, Aleksandr Vasilev wrote:
> > > > > > Hello everyone!
> > > > > >
> > > > > > I spent last few days looking at the solution to run Brooklyn
> > process
> > > > as
> > > > > a
> > > > > > daemon and found two options:
> > > > > > 1. Run daemon via Apache Commons Daemon (jsvc)
> > > > > > 2. Write a custom daemon in C
> > > > > >
> > > > > > Both solutions has its own pros and cons, so let's look at what I
> > > think
> > > > > > they are:
> > > > > >
> > > > > > JSVC:
> > > > > > Pros:
> > > > > > - Ready to use solution. Running a daemon via jsvc is very
> similar
> > to
> > > > > > running java application from the command line with similar
> > arguments
> > > > > > passed.
> > > > > > - Builds as usual in Maven
> > > > > >
> > > > > > Cons:
> > > > > > - Still requires you to write daemon code, which in my opinion
> > kills
> > > > the
> > > > > > out-of-the-box usability
> > > > > > - Has tons of bugs, including: not been able to find classes in
>

Re: Brooklyn Daemon Solution

[John McCabe]

Hi Aleksandr,

> 1. Proper detaching from the parent process, making daemon more secure
> 2. Proper detaching from any TTYs, making daemon even more secure

 Regarding the security implications when using a script vs a binary, could
you explain?

> 3. Proper redirection of all file descriptors, helps with debugging and
> logging

with file descriptor redirection, beyond stderr, stdout what are you
considering here?

> 5. More flexible solution: ability to run Brooklyn with any arguments,
> service script will have "brooklyn launch" part hardcoded and will require
> to edit the code each time you need to run it with the new args.

are you intending this to be used outside of init? we'd have the config set
externally to the daemon

> Overall I see the native daemon solution as more traditional and compliant
> to Linux standards than just wrapping bash script in yet another script.

we don't have to wrap a script surely? the init script doesn't have to call
the brooklyn script.

All the best,
John

On Fri, Jan 29, 2016 at 2:58 PM, Aleksandr Vasilev <
aleksandr.vasi...@cloudsoftcorp.com> wrote:

> Hi Alex,
>
> The advantages of having a native daemon in my opinion are:
> 1. Proper detaching from the parent process, making daemon more secure
> 2. Proper detaching from any TTYs, making daemon even more secure
> 3. Proper redirection of all file descriptors, helps with debugging and
> logging
> 4. More portable solution, as the daemon can be used in any type of service
> scripts or even on its own, not only systemd script
> 5. More flexible solution: ability to run Brooklyn with any arguments,
> service script will have "brooklyn launch" part hardcoded and will require
> to edit the code each time you need to run it with the new args.
>
> Overall I see the native daemon solution as more traditional and compliant
> to Linux standards than just wrapping bash script in yet another script.
>
> Best Regards,
> Aleksandr Vasilev
> DevOps Engineer | Cloudsoft Corporation
>
> On 29 January 2016 at 17:30, John McCabe  wrote:
>
> > [bumping so aleks can see the thread]
> >
> > On Thu, 28 Jan 2016 at 16:41 Andrew Kennedy <
> > andrew.kenn...@cloudsoftcorp.com> wrote:
> >
> > > Or what about running a Brooklyn Docker image as a systemd service!
> > >
> > > -
> http://container-solutions.com/running-docker-containers-with-systemd/
> > > - https://github.com/ibuildthecloud/systemd-docker
> > >
> > > Andrew.
> > >
> > > On Thu, 28 Jan 2016 at 16:34 Alex Heneveld <
> > > alex.henev...@cloudsoftcorp.com>
> > > wrote:
> > >
> > > >
> > > > Hi Aleksandr-
> > > >
> > > > What's the advantage of a native daemon over just wrapping it as a
> > linux
> > > > service script ?
> > > >
> > > > Best
> > > > Alex
> > > >
> > > >
> > > > On 28/01/2016 11:32, Aleksandr Vasilev wrote:
> > > > > Hello everyone!
> > > > >
> > > > > I spent last few days looking at the solution to run Brooklyn
> process
> > > as
> > > > a
> > > > > daemon and found two options:
> > > > > 1. Run daemon via Apache Commons Daemon (jsvc)
> > > > > 2. Write a custom daemon in C
> > > > >
> > > > > Both solutions has its own pros and cons, so let's look at what I
> > think
> > > > > they are:
> > > > >
> > > > > JSVC:
> > > > > Pros:
> > > > > - Ready to use solution. Running a daemon via jsvc is very similar
> to
> > > > > running java application from the command line with similar
> arguments
> > > > > passed.
> > > > > - Builds as usual in Maven
> > > > >
> > > > > Cons:
> > > > > - Still requires you to write daemon code, which in my opinion
> kills
> > > the
> > > > > out-of-the-box usability
> > > > > - Has tons of bugs, including: not been able to find classes in
> > > > classpath,
> > > > > not been able to run by non-root users, not been able to run on
> > several
> > > > > *nix systems (Mac OS, BSD)
> > > > > - The codebase hasn't changed since 2013 and seems abandoned
> > > > > - SVN repo often isn't accessible for some reason, right now the
> > > > webserver
> > > > > returns 503 error code:
> > > > > http://svn.apache.org/viewvc/commons/proper/daemon/trunk/
> > > > >
> > > > > Custom Daemon (written in C):
> > > > > Pros:
> > > > > - Cross-platform, runs on any *nix system supported by Brooklyn
> > > > > - Very little code to maintain
> > > > > - Independent from third-party solutions, requires only gcc to
> build
> > > > > - Easy to make LSB-compliant init scripts to control the daemon
> > > > >
> > > > > Cons:
> > > > > - Requires some overhead to build C code in Maven
> > > > >
> > > > > Having all these options considered, I propose writing daemon for
> > > Apache
> > > > > Brooklyn in C language and use gcc compiler to build it. It will
> > > require
> > > > > introducing some changes to Maven build process, but there are
> plenty
> > > of
> > > > > solutions for doing this, such as Maven NAR plugin, which is
> actively
> > > > > maintained:
> > > > > https://github.com/maven-nar/nar-maven-plugin
> > > > >
> > > > > Best Regards,
> > > > > Aleksandr Va

[GitHub] incubator-brooklyn pull request: Generate config/effector descript...

[tbouron]

Github user tbouron commented on the pull request:


https://github.com/apache/incubator-brooklyn/pull/1176#issuecomment-176809380
  
@bostko Didn't notice that. Let's not reintroduce a slow process then.

However, I quite like the @iyovcheva's idea of generate the `JS` **and** ` 
JSON` file. That will be much more safer and easier for the community catalog :)


---
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] incubator-brooklyn pull request: Generate config/effector descript...

[iyovcheva]

Github user iyovcheva commented on a diff in the pull request:

https://github.com/apache/incubator-brooklyn/pull/1176#discussion_r51270639
  
--- Diff: 
brooklyn-server/server-cli/src/main/java/org/apache/brooklyn/cli/ItemLister.java
 ---
@@ -98,88 +115,150 @@ public Void call() throws Exception {
 List urls = getUrls();
 LOG.info("Retrieving objects from "+urls);
 
-// TODO Remove duplication from separate ListPolicyCommand etc
-List> entityTypes = getTypes(urls, 
Entity.class);
-List> policyTypes = getTypes(urls, 
Policy.class);
-List> enricherTypes = getTypes(urls, 
Enricher.class);
-List> locationTypes = getTypes(urls, 
Location.class, Boolean.FALSE);
+Map result = MutableMap.of();
+List jsonList = new ArrayList<>();
 
-Map result = ImmutableMap.builder()
-.put("entities", 
ItemDescriptors.toItemDescriptors(entityTypes, headingsOnly, "name"))
-.put("policies", 
ItemDescriptors.toItemDescriptors(policyTypes, headingsOnly, "name"))
-.put("enrichers", 
ItemDescriptors.toItemDescriptors(enricherTypes, headingsOnly, "name"))
-.put("locations", 
ItemDescriptors.toItemDescriptors(locationTypes, headingsOnly, "type"))
-.put("locationResolvers", 
ItemDescriptors.toItemDescriptors(ImmutableList.copyOf(ServiceLoader.load(LocationResolver.class)),
 true))
-.build();
+if (!jars.isEmpty()) {
+// TODO Remove duplication from separate ListPolicyCommand 
etc
+List> entityTypes = getTypes(urls, 
Entity.class);
+List> policyTypes = getTypes(urls, 
Policy.class);
+List> enricherTypes = 
getTypes(urls, Enricher.class);
+List> locationTypes = 
getTypes(urls, Location.class, Boolean.FALSE);
 
-String json = toJson(result);
+result = ImmutableMap.builder()
+.put("entities", 
ItemDescriptors.toItemDescriptors(entityTypes, headingsOnly, "name"))
+.put("policies", 
ItemDescriptors.toItemDescriptors(policyTypes, headingsOnly, "name"))
+.put("enrichers", 
ItemDescriptors.toItemDescriptors(enricherTypes, headingsOnly, "name"))
+.put("locations", 
ItemDescriptors.toItemDescriptors(locationTypes, headingsOnly, "type"))
+.put("locationResolvers", 
ItemDescriptors.toItemDescriptors(ImmutableList.copyOf(ServiceLoader.load(LocationResolver.class)),
 true))
+.build();
+jsonList.add(toJson(result));
+} else if (!yaml.isEmpty()) {
+LocalManagementContext lmgmt = new 
LocalManagementContext();
+BrooklynCampPlatform platform = new BrooklynCampPlatform(
+PlatformRootSummary.builder().name("Brooklyn CAMP 
Platform").build(),lmgmt)
+.setConfigKeyAtManagmentContext();
+BrooklynCatalog catalog = lmgmt.getCatalog();
 
-if (outputFolder == null) {
-System.out.println(json);
-} else {
-LOG.info("Outputting item list (size "+itemCount+") to " + 
outputFolder);
-String outputPath = Os.mergePaths(outputFolder, 
"index.html");
-String parentDir = (new 
File(outputPath).getParentFile()).getAbsolutePath();
-mkdir(parentDir, "entities");
-mkdir(parentDir, "policies");
-mkdir(parentDir, "enrichers");
-mkdir(parentDir, "locations");
-mkdir(parentDir, "locationResolvers"); //TODO nothing 
written here yet...
-
-mkdir(parentDir, "style");
-mkdir(Os.mergePaths(parentDir, "style"), "js");
-mkdir(Os.mergePaths(parentDir, "style", "js"), "catalog");
-
-Files.write("var items = " + json, new 
File(Os.mergePaths(outputFolder, "items.js")), Charsets.UTF_8);
-ResourceUtils resourceUtils = ResourceUtils.create(this);
-
-// root - just loads the above JSON
-
copyFromItemListerClasspathBaseStaticsToOutputDir(resourceUtils, 
"brooklyn-object-list.html", "index.html");
-
-// statics - structure mirrors docs (not for any real 
reason however... the json is usually enough for our docs)
-
copyFromItemListerClasspathBaseStaticsToOutputDir(resourceUtils, "common.js");
-
copyFromItemListerClasspathBaseStatic

Re: Brooklyn Daemon Solution

[Aleksandr Vasilev]

Hi Alex,

The advantages of having a native daemon in my opinion are:
1. Proper detaching from the parent process, making daemon more secure
2. Proper detaching from any TTYs, making daemon even more secure
3. Proper redirection of all file descriptors, helps with debugging and
logging
4. More portable solution, as the daemon can be used in any type of service
scripts or even on its own, not only systemd script
5. More flexible solution: ability to run Brooklyn with any arguments,
service script will have "brooklyn launch" part hardcoded and will require
to edit the code each time you need to run it with the new args.

Overall I see the native daemon solution as more traditional and compliant
to Linux standards than just wrapping bash script in yet another script.

Best Regards,
Aleksandr Vasilev
DevOps Engineer | Cloudsoft Corporation

On 29 January 2016 at 17:30, John McCabe  wrote:

> [bumping so aleks can see the thread]
>
> On Thu, 28 Jan 2016 at 16:41 Andrew Kennedy <
> andrew.kenn...@cloudsoftcorp.com> wrote:
>
> > Or what about running a Brooklyn Docker image as a systemd service!
> >
> > - http://container-solutions.com/running-docker-containers-with-systemd/
> > - https://github.com/ibuildthecloud/systemd-docker
> >
> > Andrew.
> >
> > On Thu, 28 Jan 2016 at 16:34 Alex Heneveld <
> > alex.henev...@cloudsoftcorp.com>
> > wrote:
> >
> > >
> > > Hi Aleksandr-
> > >
> > > What's the advantage of a native daemon over just wrapping it as a
> linux
> > > service script ?
> > >
> > > Best
> > > Alex
> > >
> > >
> > > On 28/01/2016 11:32, Aleksandr Vasilev wrote:
> > > > Hello everyone!
> > > >
> > > > I spent last few days looking at the solution to run Brooklyn process
> > as
> > > a
> > > > daemon and found two options:
> > > > 1. Run daemon via Apache Commons Daemon (jsvc)
> > > > 2. Write a custom daemon in C
> > > >
> > > > Both solutions has its own pros and cons, so let's look at what I
> think
> > > > they are:
> > > >
> > > > JSVC:
> > > > Pros:
> > > > - Ready to use solution. Running a daemon via jsvc is very similar to
> > > > running java application from the command line with similar arguments
> > > > passed.
> > > > - Builds as usual in Maven
> > > >
> > > > Cons:
> > > > - Still requires you to write daemon code, which in my opinion kills
> > the
> > > > out-of-the-box usability
> > > > - Has tons of bugs, including: not been able to find classes in
> > > classpath,
> > > > not been able to run by non-root users, not been able to run on
> several
> > > > *nix systems (Mac OS, BSD)
> > > > - The codebase hasn't changed since 2013 and seems abandoned
> > > > - SVN repo often isn't accessible for some reason, right now the
> > > webserver
> > > > returns 503 error code:
> > > > http://svn.apache.org/viewvc/commons/proper/daemon/trunk/
> > > >
> > > > Custom Daemon (written in C):
> > > > Pros:
> > > > - Cross-platform, runs on any *nix system supported by Brooklyn
> > > > - Very little code to maintain
> > > > - Independent from third-party solutions, requires only gcc to build
> > > > - Easy to make LSB-compliant init scripts to control the daemon
> > > >
> > > > Cons:
> > > > - Requires some overhead to build C code in Maven
> > > >
> > > > Having all these options considered, I propose writing daemon for
> > Apache
> > > > Brooklyn in C language and use gcc compiler to build it. It will
> > require
> > > > introducing some changes to Maven build process, but there are plenty
> > of
> > > > solutions for doing this, such as Maven NAR plugin, which is actively
> > > > maintained:
> > > > https://github.com/maven-nar/nar-maven-plugin
> > > >
> > > > Best Regards,
> > > > Aleksandr Vasilev
> > > > DevOps Engineer | Cloudsoft Corporation
> > > >
> > >
> > > --
> >
> > Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
> >
>

[GitHub] incubator-brooklyn pull request: Improvements to brooklyn-server/r...

[andreaturli]

Github user andreaturli closed the pull request at:

https://github.com/apache/incubator-brooklyn/pull/1177


---
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] incubator-brooklyn pull request: Improvements to brooklyn-server/r...

[andreaturli]

GitHub user andreaturli reopened a pull request:

https://github.com/apache/incubator-brooklyn/pull/1177

Improvements to brooklyn-server/rest/rest-api

- remove duplication of jackson and jackson2 on brooklyn project
- refactor pojos to have a consistent `toString`, `hashCode` and `equals`
- refactor pojos to use jackson2 
- adapt code to the new jackson2 api where needed

@ahgittin I'd appreciate your thoughts particularly on 
`BrooklynJacksonJsonProvider` as jackson api are significantly changed in that 
area.

Notice this is not ready to be merged as even if `brooklyn-server/rest` 
sub-modules are building fine, but karaf section need to be fixed. I'd 
appreciate any help from karaf experts.

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

$ git pull https://github.com/andreaturli/incubator-brooklyn 
improvement/rest-api

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

https://github.com/apache/incubator-brooklyn/pull/1177.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 #1177


commit 73260ed0e56fe75f8fe859d4571ebd4f0abf5159
Author: Andrea Turli 
Date:   2016-01-22T17:08:13Z

Initial work to simplify the rest server

- remove JsonNode from API interfaces
- refactor consistently toStringand hashCode and equals for the domain 
objects
- remove deprecated code
- simplified pom dependencies

commit 151ec2f9e5efcddc1bec65d9f1c1fbfe641c3118
Author: Andrea Turli 
Date:   2016-01-26T12:00:11Z

remove com.codehaus.jackson dependency and promote com.fasterxml.jackson 
usage

commit 93d753553925d60ba9c4264c3aab635036720cc1
Author: Andrea Turli 
Date:   2016-01-27T11:46:41Z

More fixes to support jackson 2

- adjust BrooklynJacksonSerializer to use jackson 2 api
- fix web.xml for rest-api and rest-client




---
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] incubator-brooklyn pull request: Improvements to brooklyn-server/r...

[andreaturli]

Github user andreaturli commented on the pull request:


https://github.com/apache/incubator-brooklyn/pull/1177#issuecomment-176789869
  
thanks @CMoH 
Anyway I see problems with jenkins with this PR as well. I'll try closing 
and reopening it to force a new build if it was just temporary.


---
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] incubator-brooklyn pull request: Improvements to brooklyn-server/r...

[CMoH]

Github user CMoH commented on a diff in the pull request:

https://github.com/apache/incubator-brooklyn/pull/1177#discussion_r51266731
  
--- Diff: brooklyn-server/karaf/features/src/main/history/dependencies.xml 
---
@@ -0,0 +1,103 @@
+
--- End diff --

I have removed the file and supposedly the pom instructions that generate 
it. If the file keeps reappearing we can gitignore it, and ungitignore+add it 
later on if we need it.


---
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] incubator-brooklyn pull request: Improvements to brooklyn-server/r...

[CMoH]

Github user CMoH commented on the pull request:


https://github.com/apache/incubator-brooklyn/pull/1177#issuecomment-176781901
  
Feel free to merge before #1140. That PR already has merge conflicts, that 
will more time to resolve anyway. I think there's no point holding this back in 
the meantime.


---
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: Brooklyn Daemon Solution

[John McCabe]

[bumping so aleks can see the thread]

On Thu, 28 Jan 2016 at 16:41 Andrew Kennedy <
andrew.kenn...@cloudsoftcorp.com> wrote:

> Or what about running a Brooklyn Docker image as a systemd service!
>
> - http://container-solutions.com/running-docker-containers-with-systemd/
> - https://github.com/ibuildthecloud/systemd-docker
>
> Andrew.
>
> On Thu, 28 Jan 2016 at 16:34 Alex Heneveld <
> alex.henev...@cloudsoftcorp.com>
> wrote:
>
> >
> > Hi Aleksandr-
> >
> > What's the advantage of a native daemon over just wrapping it as a linux
> > service script ?
> >
> > Best
> > Alex
> >
> >
> > On 28/01/2016 11:32, Aleksandr Vasilev wrote:
> > > Hello everyone!
> > >
> > > I spent last few days looking at the solution to run Brooklyn process
> as
> > a
> > > daemon and found two options:
> > > 1. Run daemon via Apache Commons Daemon (jsvc)
> > > 2. Write a custom daemon in C
> > >
> > > Both solutions has its own pros and cons, so let's look at what I think
> > > they are:
> > >
> > > JSVC:
> > > Pros:
> > > - Ready to use solution. Running a daemon via jsvc is very similar to
> > > running java application from the command line with similar arguments
> > > passed.
> > > - Builds as usual in Maven
> > >
> > > Cons:
> > > - Still requires you to write daemon code, which in my opinion kills
> the
> > > out-of-the-box usability
> > > - Has tons of bugs, including: not been able to find classes in
> > classpath,
> > > not been able to run by non-root users, not been able to run on several
> > > *nix systems (Mac OS, BSD)
> > > - The codebase hasn't changed since 2013 and seems abandoned
> > > - SVN repo often isn't accessible for some reason, right now the
> > webserver
> > > returns 503 error code:
> > > http://svn.apache.org/viewvc/commons/proper/daemon/trunk/
> > >
> > > Custom Daemon (written in C):
> > > Pros:
> > > - Cross-platform, runs on any *nix system supported by Brooklyn
> > > - Very little code to maintain
> > > - Independent from third-party solutions, requires only gcc to build
> > > - Easy to make LSB-compliant init scripts to control the daemon
> > >
> > > Cons:
> > > - Requires some overhead to build C code in Maven
> > >
> > > Having all these options considered, I propose writing daemon for
> Apache
> > > Brooklyn in C language and use gcc compiler to build it. It will
> require
> > > introducing some changes to Maven build process, but there are plenty
> of
> > > solutions for doing this, such as Maven NAR plugin, which is actively
> > > maintained:
> > > https://github.com/maven-nar/nar-maven-plugin
> > >
> > > Best Regards,
> > > Aleksandr Vasilev
> > > DevOps Engineer | Cloudsoft Corporation
> > >
> >
> > --
>
> Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
>

[GitHub] incubator-brooklyn pull request: Create Password Sensor

[duncangrant]

Github user duncangrant commented on the pull request:


https://github.com/apache/incubator-brooklyn/pull/1169#issuecomment-176694764
  
I think I've made all the changes that I've been asked for.  If everything 
is ok then please let me know if I should squash my commits before merging. 


---
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] incubator-brooklyn pull request: Generate config/effector descript...

[bostko]

Github user bostko commented on the pull request:


https://github.com/apache/incubator-brooklyn/pull/1176#issuecomment-176651040
  
@tbouron @neykov if you had noticed docs were loading from a json file for 
a while.
However I noticed the experience wasn't so smooth on production and 
reverted it back.
When it is js file in the html it is automatically cached by the browser 
with no extra code.
https://github.com/apache/incubator-brooklyn/pull/622


---
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] incubator-brooklyn pull request: Uses externally accessible addres...

[nakomis]

GitHub user nakomis reopened a pull request:

https://github.com/apache/incubator-brooklyn/pull/1168

Uses externally accessible address for main uri of controller

Previously, if deploying to BYON AWS instances, the internal IP address was 
being displayed in the main.uri for the ControlledDynamicWebAppCluster

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

$ git pull https://github.com/nakomis/incubator-brooklyn 
fix/abstract-controller-main-ui

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

https://github.com/apache/incubator-brooklyn/pull/1168.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 #1168


commit c91d7ebbc3e62f5f3b2f9e2da883df1f84957f2c
Author: Martin Harris 
Date:   2016-01-21T16:40:35Z

Uses externally accessible address for main uri of controller




---
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] incubator-brooklyn pull request: Uses externally accessible addres...

[nakomis]

Github user nakomis closed the pull request at:

https://github.com/apache/incubator-brooklyn/pull/1168


---
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.
---