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

[Mike Zaccardo (JIRA)]

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

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

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

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

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

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

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

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

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

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

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

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



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

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

[Mike Zaccardo (JIRA)]

Mike Zaccardo created BROOKLYN-439:
--

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


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

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

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

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



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

[GitHub] brooklyn-library issue #34: Fix sed command that update the MySQL configurat...

[tbouron]

Github user tbouron commented on the issue:

https://github.com/apache/brooklyn-library/pull/34
  
Close in favor or #76 (my PR wasn't really working anyway)


---
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 #34: Fix sed command that update the MySQL con...

[tbouron]

Github user tbouron closed the pull request at:

https://github.com/apache/brooklyn-library/pull/34


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

Jenkins build is back to normal : brooklyn-master-build #831

[Apache Jenkins Server]

See 

Jenkins build is back to normal : brooklyn-server-master #456

[Apache Jenkins Server]

See 

[GitHub] brooklyn-server issue #480: Config self reference fix

[ahgittin]

Github user ahgittin commented on the issue:

https://github.com/apache/brooklyn-server/pull/480
  
Pretty sure the failures reported 
[here](https://builds.apache.org/job/brooklyn-server-pull-requests/1728/) are 
unrelated:

```
* 
org.apache.brooklyn.launcher.CleanOrphanedLocationsIntegrationTest.testCleanedCopiedPersistedState
* 
org.apache.brooklyn.launcher.CleanOrphanedLocationsIntegrationTest.testSelectionWithOrphanedLocationsInData
```

Both pass for me locally.  (Incidentally @aledsage none of the tests in 
that class are marked "Integration".)


---
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-server issue #531: initial work to support HttpEntity

[andreaturli]

Github user andreaturli commented on the issue:

https://github.com/apache/brooklyn-server/pull/531
  
I will open a PR for docs ASAP, thanks @ahgittin for merging 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] brooklyn-server pull request #555: Add DurationPredicates

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-server pull request #531: initial work to support HttpEntity

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-server issue #531: initial work to support HttpEntity

[ahgittin]

Github user ahgittin commented on the issue:

https://github.com/apache/brooklyn-server/pull/531
  
very nice @andreaturli -- and excellent tests.

is there a corresponding PR against the docs to explain how to use this?

looks good so 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] brooklyn-server issue #546: Sequencer entity

[ahgittin]

Github user ahgittin commented on the issue:

https://github.com/apache/brooklyn-server/pull/546
  
I feel like this will soon be superseded, by being able to point at some 
shared-scoped atomic integer and request a `getAndIncrement` directly in YAML 
as part of `start`.  Haven't looked in detail but if that impl could be done as 
an extension of `DynamicGroup` could the code here be simplified?

That said not that opposed to adding for now if useful with an expectation 
it might fall away.


---
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-server issue #554: Ensured the \n character is escaped when escapin...

[ahgittin]

Github user ahgittin commented on the issue:

https://github.com/apache/brooklyn-server/pull/554
  
-1

I think some shells don't respect `\n` so this could break things all over 
the place.  The norm in shells is for double-quoted strings to be allowed to 
have a new line, so we should _not_ escape it as `\n`.

If the issue is to ensure that a string fits on a single line I think you 
have to look at a different escaping mechanism.



---
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-server issue #555: Add DurationPredicates

[ahgittin]

Github user ahgittin commented on the issue:

https://github.com/apache/brooklyn-server/pull/555
  
LGTM


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

Build failed in Jenkins: brooklyn-server-master #455

[Apache Jenkins Server]

See 

Changes:

[alex] migrate config inheritance to new classes

[alex] document better config inheritance semantics

[alex] implement inheritance of config default values

[alex] uncomment another assertion about inherited config

[alex] don't use transients as not reset on deserialization

[alex] PR comments on config defaults

[alex] no need for `keepSameInstance` in `RebindOptions` as we have a field

[alex] comments on parameter/config inheritance/merging

[alex] fix test for taking default from parameter

[alex] fix version reference in config inheritance test

[alex] improve methods for retrieving config keys

[alex] need to restrict keys to those present for ssh commands

[alex] merge default values in config inheritance

[alex] clean up SpecParameterUnwrappingTest

[alex] fix merge wrapper semantics to combine parameters not overwrite

[alex.heneveld] address most PR comments

[alex.heneveld] newly deprecated items now refer to 0.11.0 not 0.10.0

[alex.heneveld] add failing test from @geomacy

[alex.heneveld] align signature as per PR comment, and trivial 
deprecation/warning fixes

[alex.heneveld] Config inheritance: test improvements

[alex.heneveld] use constants for the count checks in 
SpecParameterUnwrappingTest

[alex.heneveld] fix so that list of declared config keys excludes those not 
reinherited

[alex.heneveld] cleanup spec parameter parsing/inheriting, tidy misc tests

[alex.heneveld] address PR comment, move list recompute to after loop

--
[...truncated 21097 lines...]
2017-02-15 18:43:25,596 INFO  TESTNG INVOKING: "Surefire test" - 
org.apache.brooklyn.core.entity.lifecycle.ServiceStateLogicTest.testTwoIndicatorsAreBetterThanOne()
2017-02-15 18:43:25,599 INFO  TESTNG PASSED: "Surefire test" - 
org.apache.brooklyn.core.entity.lifecycle.ServiceStateLogicTest.testTwoIndicatorsAreBetterThanOne()
 finished in 3 ms
2017-02-15 18:43:25,599 INFO  TESTNG INVOKING CONFIGURATION: "Surefire test" - 
@AfterMethod 
org.apache.brooklyn.core.test.BrooklynMgmtUnitTestSupport.tearDown()
2017-02-15 18:43:25,608 INFO  TESTNG PASSED CONFIGURATION: "Surefire test" - 
@AfterMethod 
org.apache.brooklyn.core.test.BrooklynMgmtUnitTestSupport.tearDown() finished 
in 8 ms
:created
:starting
:running
:stopping
:stopped
:destroyed
:on-fire
2017-02-15 18:43:25,609 INFO  TESTNG INVOKING: "Surefire test" - 
org.apache.brooklyn.core.entity.lifecycle.LifecycleTransitionTest.testTransitionCoalesce(org.apache.brooklyn.core.entity.lifecycle.Lifecycle)(value(s):
 created)
2017-02-15 18:43:25,610 INFO  TESTNG PASSED: "Surefire test" - 
org.apache.brooklyn.core.entity.lifecycle.LifecycleTransitionTest.testTransitionCoalesce(org.apache.brooklyn.core.entity.lifecycle.Lifecycle)(value(s):
 created) finished in 1 ms
2017-02-15 18:43:25,611 INFO  TESTNG INVOKING: "Surefire test" - 
org.apache.brooklyn.core.entity.lifecycle.LifecycleTransitionTest.testTransitionCoalesce(org.apache.brooklyn.core.entity.lifecycle.Lifecycle)(value(s):
 starting)
2017-02-15 18:43:25,611 INFO  TESTNG PASSED: "Surefire test" - 
org.apache.brooklyn.core.entity.lifecycle.LifecycleTransitionTest.testTransitionCoalesce(org.apache.brooklyn.core.entity.lifecycle.Lifecycle)(value(s):
 starting) finished in 0 ms
2017-02-15 18:43:25,611 INFO  TESTNG INVOKING: "Surefire test" - 
org.apache.brooklyn.core.entity.lifecycle.LifecycleTransitionTest.testTransitionCoalesce(org.apache.brooklyn.core.entity.lifecycle.Lifecycle)(value(s):
 running)
2017-02-15 18:43:25,611 INFO  TESTNG PASSED: "Surefire test" - 
org.apache.brooklyn.core.entity.lifecycle.LifecycleTransitionTest.testTransitionCoalesce(org.apache.brooklyn.core.entity.lifecycle.Lifecycle)(value(s):
 running) finished in 0 ms
2017-02-15 18:43:25,611 INFO  TESTNG INVOKING: "Surefire test" - 
org.apache.brooklyn.core.entity.lifecycle.LifecycleTransitionTest.testTransitionCoalesce(org.apache.brooklyn.core.entity.lifecycle.Lifecycle)(value(s):
 stopping)
2017-02-15 18:43:25,612 INFO  TESTNG PASSED: "Surefire test" - 
org.apache.brooklyn.core.entity.lifecycle.LifecycleTransitionTest.testTransitionCoalesce(org.apache.brooklyn.core.entity.lifecycle.Lifecycle)(value(s):
 stopping) finished in 0 ms
2017-02-15 18:43:25,612 INFO  TESTNG INVOKING: "Surefire test" - 
org.apache.brooklyn.core.entity.lifecycle.LifecycleTransitionTest.testTransitionCoalesce(org.apache.brooklyn.core.entity.lifecycle.Lifecycle)(value(s):
 stopped)
2017-02-15 18:43:25,612 INFO  TESTNG PASSED: "Surefire test" - 
org.apache.brooklyn.core.entity.lifecycle.LifecycleTransitionTest.testTransitionCoalesce(org.apache.brooklyn.core.entity.lifecycle.Lifecycle)(value(s):
 stopped) finished in 0 ms
2017-02-15 18:43:25,612 INFO  TESTNG INVOKING: "Surefire test" - 
org.apache.brooklyn.core.entity.lifecycle.LifecycleTransitionTest.testTransitionCoalesce(org.apache.brooklyn.core.entity.lifecycle.Lifecycle)(value(s):
 destroyed)
2017-02-15 18:43:25,612 

[jira] [Commented] (BROOKLYN-267) brooklyn.parameter default value not picked up via inherited config

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on BROOKLYN-267:
-

Github user asfgit closed the pull request at:

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


> brooklyn.parameter default value not picked up via inherited config
> ---
>
> Key: BROOKLYN-267
> URL: https://issues.apache.org/jira/browse/BROOKLYN-267
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 0.9.0
>Reporter: Aled Sage
>Priority: Minor
>
> When adding the item below to the catalog, I get surprising behaviour when 
> retrieving the "test.myconf" parameter at different levels.
> When inside a child entity, trying to do {{$brooklyn:config("test.myconf")}}, 
> it returns null. But if I do {{$brooklyn:root().config("test.myconf")}} then 
> it works as I'd expect (i.e. I get the default value).
> {noformat}
> brooklyn.catalog:
>   id: my-example
>   version: 1.2.3
>   item:
> brooklyn.parameters:
> - name: test.myconf
>   type:  string
>   default: myval
> services:
> - type: org.apache.brooklyn.entity.stock.BasicApplication
>   brooklyn.config:
> myconf2: $brooklyn:config("test.myconf")
> myconf2.from.root: $brooklyn:root().config("test.myconf")
>   brooklyn.children:
>   - type: org.apache.brooklyn.entity.stock.BasicEntity
> brooklyn.config:
>   myconf3: $brooklyn:config("test.myconf")
>   myconf3.from.root: $brooklyn:root().config("test.myconf")
> {noformat}
> The reason, I believe, is that {{$brooklyn:config("test.myconf")}} on the 
> child will lookup the child's explicitly defined config keys and not find 
> any. It will therefore create a new {{ConfigKey}} object with no default 
> value. It looks up its own config and then the inherited config, but sees no 
> explicit value set. So it falls back to the configKey.defaultValue. But 
> because we synthesised a new config key object, we don't get the default 
> value that was defined in the {{brooklyn.parameters}} section.
> ---
> Overall, I think it's best if:
> * our exemplar blueprints use things like 
> {{$brooklyn:root().config("test.myconf")}} (because that has a very clear 
> meaning);
> * and we change our config key lookup so that we only synthesis a config key 
> object if none of the current entity or any of its ancestors in the parent 
> hierarchy has a matching config key.
> For point (2), this could lead to surprising behaviour in edge cases where a 
> hierarchy of entities includes something pulled in from another entity type 
> in the catalog, and where that entity type happens to declare a config key by 
> the same name with a default value. At that point, the user looking at their 
> own yaml file might be surprised that it didn't pick up the default value 
> they are looking at in front of them.



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

[GitHub] brooklyn-server pull request #462: Inherit config default values

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-server pull request #529: LocationNetworkInfoCustomizer

[sjcorbett]

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

https://github.com/apache/brooklyn-server/pull/529#discussion_r101334570
  
--- Diff: 
locations/jclouds/src/main/java/org/apache/brooklyn/location/jclouds/BasicLocationNetworkInfoCustomizer.java
 ---
@@ -0,0 +1,472 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.brooklyn.location.jclouds;
+
+import java.util.Iterator;
+import java.util.Map;
+
+import org.apache.brooklyn.api.entity.Entity;
+import org.apache.brooklyn.api.entity.EntityInitializer;
+import org.apache.brooklyn.api.entity.EntityLocal;
+import org.apache.brooklyn.api.sensor.AttributeSensor;
+import org.apache.brooklyn.config.ConfigKey;
+import org.apache.brooklyn.core.config.ConfigKeys;
+import org.apache.brooklyn.core.entity.Attributes;
+import org.apache.brooklyn.core.entity.BrooklynConfigKeys;
+import org.apache.brooklyn.core.location.LocationConfigKeys;
+import org.apache.brooklyn.core.mgmt.BrooklynTaskTags;
+import org.apache.brooklyn.core.sensor.Sensors;
+import org.apache.brooklyn.location.winrm.WinRmMachineLocation;
+import org.apache.brooklyn.util.core.config.ConfigBag;
+import org.apache.brooklyn.util.core.task.Tasks;
+import org.apache.brooklyn.util.exceptions.Exceptions;
+import org.apache.brooklyn.util.guava.Maybe;
+import org.apache.brooklyn.util.net.Networking;
+import org.apache.brooklyn.util.time.Duration;
+import org.jclouds.compute.domain.NodeMetadata;
+import org.jclouds.domain.LoginCredentials;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import com.google.common.annotations.Beta;
+import com.google.common.base.MoreObjects;
+import com.google.common.base.Optional;
+import com.google.common.base.Predicate;
+import com.google.common.base.Stopwatch;
+import com.google.common.base.Supplier;
+import com.google.common.base.Suppliers;
+import com.google.common.collect.ImmutableList;
+import com.google.common.collect.Iterables;
+import com.google.common.net.HostAndPort;
+
+/**
+ * BasicLocationNetworkInfoCustomizer provides the default implementation 
of
+ * {@link LocationNetworkInfoCustomizer}. It exposes options to have 
JcloudsLocation
+ * prefer to contact VMs on private addresses and can be injected on a
+ * per-entity basis. For example:
+ * 
+ * services:
+ * - type: server
+ *   location: the-same-private-network-as-brooklyn
+ *   brooklyn.initializers:
+ *   - type: 
org.apache.brooklyn.location.jclouds.BasicLocationNetworkInfoCustomizer
+ * brooklyn.config:
+ *   mode: ONLY_PRIVATE
+ * - type: server
+ *   location: another-cloud
+ *   # implicit use of PREFER_PUBLIC.
+ * 
+ * Would result in the first entity being managed on the instance's 
private address (and deployment
+ * failing if this was not possible) and the second being managed on its 
public address. Graceful
+ * fallback is possible by replacing ONLY_PRIVATE with PREFER_PRIVATE. 
There are PUBLIC variants of
+ * each of these.
+ * 
+ * BasicLocationNetworkInfoCustomizer is the default location network info 
customizer used by
+ * {@link JcloudsLocation} when {@link 
JcloudsLocationConfig#LOCATION_NETWORK_INFO_CUSTOMIZER}
+ * is unset.
+ * 
+ * When used as an {@link EntityInitializer} the instance inserts itself 
into the entity's
+ * provisioning properties under the {@link 
JcloudsLocationConfig#LOCATION_NETWORK_INFO_CUSTOMIZER}
+ * subkey.
+ * 
+ * This class is annotated @Beta and is likely to change in the future.
+ */
+@Beta
+public class BasicLocationNetworkInfoCustomizer extends 
BasicJcloudsLocationCustomizer implements LocationNetworkInfoCustomizer {
+
+private static final Logger LOG = 
LoggerFactory.getLogger(BasicLocationNetworkInfoCustomizer.class);
+
+public enum NetworkMode {
+/**
+ * Check each node's {@link NodeMetadata#getPublicAddresses() 

[GitHub] brooklyn-server pull request #462: Inherit config default values

[neykov]

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

https://github.com/apache/brooklyn-server/pull/462#discussion_r101306815
  
--- Diff: 
utils/common/src/main/java/org/apache/brooklyn/util/guava/Maybe.java ---
@@ -457,6 +457,8 @@ public boolean equals(Object obj) {
 Maybe other = (Maybe)obj;
 if (!isPresent()) 
 return !other.isPresent();
+if (!other.isPresent())
+return false;
--- End diff --

Don't mind me, somehow missed the previous check where two absents will be 
equal.
My impression was exactly the opposite, that with the change two absents 
are never equal, even for `this.equals(this)`.


---
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-server issue #462: Inherit config default values

[ahgittin]

Github user ahgittin commented on the issue:

https://github.com/apache/brooklyn-server/pull/462
  
Good spot. Will fix and merge.



---
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-server issue #462: Inherit config default values

[ahgittin]

Github user ahgittin commented on the issue:

https://github.com/apache/brooklyn-server/pull/462
  
Could cause an issue if absents are used as keys with the intention that
they all be different but that would be weird. Have checked our hashCode
and it's a constant for absents already.



---
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-server pull request #462: Inherit config default values

[geomacy]

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

https://github.com/apache/brooklyn-server/pull/462#discussion_r101298270
  
--- Diff: 
core/src/main/java/org/apache/brooklyn/core/objs/BrooklynDynamicType.java ---
@@ -175,20 +179,29 @@ protected static void buildConfigKeys(Class clazz, Abs
 LOG.warn("cannot access config key (skipping): "+f);
 }
 }
+Collection interfaces = 
MutableSet.copyOf(Arrays.asList(clazz.getInterfaces()));
 LinkedHashSet keys = new 
LinkedHashSet(configKeysAll.keys());
 for (String kn: keys) {
 List> kk = 
Lists.newArrayList(configKeysAll.get(kn));
-if (kk.size()>1) {
-// remove anything which extends another value in the list
-for (FieldAndValue k: kk) {
-ConfigKey key = value(k);
-if (key instanceof BasicConfigKeyOverwriting) {

-ConfigKey parent = 
((BasicConfigKeyOverwriting)key).getParentKey();
-// find and remove the parent from consideration
-for (FieldAndValue k2: kk) {
-if (value(k2) == parent)
-configKeysAll.remove(kn, k2);
-}
+// remove anything which isn't reinheritable, or which is 
overridden
+for (FieldAndValue k: kk) {
+ConfigKey key = value(k);
+if (!ConfigInheritances.isKeyReinheritable(key, 
InheritanceContext.TYPE_DEFINITION)) {
+if (k.field.getDeclaringClass().equals(clazz)) {
+// proceed if key is declared on this class
+} else if 
(interfaces.contains(k.field.getDeclaringClass())) {
+// proceed if key is declared on an exlicitly 
declared interface
+} else {
+// key not re-inheritable from parent so not 
visible here
+configKeysAll.remove(k.value.getName(), k);
+}
+}
+if (key instanceof BasicConfigKeyOverwriting) {

+ConfigKey parent = 
((BasicConfigKeyOverwriting)key).getParentKey();
+// find and remove the parent from consideration
+for (FieldAndValue k2: kk) {
+if (value(k2) == parent)
+configKeysAll.remove(kn, k2);
 }
 }
 kk = Lists.newArrayList(configKeysAll.get(kn));
--- End diff --

You've moved this update of `kk` inside the `for( ... k : kk)` loop, which 
doesn't look right. Updating the list variable each time round an iterator 
initialised from that variable?


---
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: [DISCUSSION] Determining which Brooklyn node address to advertise

[Svetoslav Neykov]

> What is the benefit of the "management-private-" group? It seems 
> superfluous to me if "management-private-ingress-" will contain the 
> public IPs of the members of the cluster.


Needed for in-cloud access. Even if the public IP is white-listed, local access 
will use the private IP and will be rejected. So we either need that or need to 
include the private IP along the public IP. But then:
 * Need to figure out what's the private IP. How do you tell apart public form 
private interfaces, what if the machine is part of multiple networks. Do we 
just include all local interfaces in the SG (in addition to the public)?
 * Need to advertise it in the HA cluster metadata
 * Do we include all private IPs in all clouds? Could allow someone to 
impersonate the unused IPs. If not how do we tell which IP is for which cloud?

On one hand having the SG removes some cumbersome questions. On the other 
removing it makes the cluster self-manageable. No need for external 
intervention.




> On 15.02.2017 г., at 16:34, Sam Corbett  wrote:
> 
> Thanks for clarifying. It was this cross-cloud case I was considering.
> 
> What is the benefit of the "management-private-" group? It seems 
> superfluous to me if "management-private-ingress-" will contain the 
> public IPs of the members of the cluster.
> 
> 
> On 15/02/2017 14:16, Svetoslav Neykov wrote:
>> My response below was based on my thinking about in-cloud access between 
>> Brooklyn and the managed machines.
>> When the access is cross-cloud we indeed need _c_ security groups. Each one 
>> containing _n_ records with the public IPs of the HA cluster members. These 
>> can be managed by Brooklyn though.
>> 
>> To summarise (and get my thinking straight). In each cloud/availability zone 
>> we could have:
>> 1. "management-private-" SG assigned on the HA cluster member 
>> machines. No records in the SG.
>> 2. "management-private-ingress-" SG with first record allowing 
>> all traffic from "management-private-" (above group) and _n_ more 
>> records allowing all traffic coming from the public IPs of the HA member 
>> nodes. This one is assigned to all managed entities.
>> 
>> On adding a new member to the cluster:
>>   1. Assign "management-private-" to the new machine - this is the 
>> only action that needs to be done by the manager of the cluster
>>   2. Go to each cloud and update the "management-private-ingress-" 
>> group, adding the new public IP.
>> 
>> Svet.
>> 
>> 
>>> On 15.02.2017 г., at 15:40, Svetoslav Neykov 
>>>  wrote:
>>> 
 You propose that the manager of the Brooklyn HA cluster maintain at least 
 _c_ security groups (one per security group scope - e.g. AWS EC2 region - 
 per cloud).
>>> Not quite. It's the number of "clouds HA cluster is deployed to". That's 
>>> the number of availability zones - usually a low number 1-2-3.
>>> 
 Each of these groups has _n_ records. When the HA cluster is resized each 
 group is modified to add or remove a record as appropriate.
>>> No, they are empty. Adding a new cluster member is just assigning the SG to 
>>> the new machine. Then for each managed entity there's a record in its 
>>> security group to allow traffic from the HA security group.
>>> For clouds where there are no running HA cluster members Brooklyn will 
>>> auto-create the security group and add it to entities' security groups but 
>>> it will be unused.
>>> 
>>> The manager of the HA cluster can wait for Brooklyn to create the 
>>> "management" SG (which will contain the cluster ID in its name which is not 
>>> known in advance) and then assign it to the HA cluster members or create 
>>> one with a predefined name and configure the name in each HA instance.
>>> 
>>> Svet.
>>> 
>>> 
>>> 
 On 15.02.2017 г., at 14:59, Sam Corbett  
 wrote:
 
 Interesting problem Svet. Your proposal is a neat way of sidestepping the 
 problem of updating many security groups as the set of HA nodes changes.
 
 Let me rephrase it to see if I understand correctly.
 
 Suppose we have:
 * _n_ Brooklyn servers in an HA cluster (that could be across many clouds 
 / regions within a cloud)
 * _c_ clouds that Brooklyn can deploy to
 * _m_ instances across those clouds.
 
 We want to avoid the n+1th Brooklyn node requiring _m_ security group 
 updates.
 
 You propose that the manager of the Brooklyn HA cluster maintain at least 
 _c_ security groups (one per security group scope - e.g. AWS EC2 region - 
 per cloud). Each of these groups has _n_ records. When the HA cluster is 
 resized each group is modified to add or remove a record as appropriate.
 
 Do I have this correct?
 
 Sam
 
 
 On 14/02/2017 15:42, Svetoslav Neykov wrote:
> I'm trying to restrict access to the machines managed by Brooklyn using 
> security groups - 

Build failed in Jenkins: brooklyn-master-build #830

[Apache Jenkins Server]

See 

--
[...truncated 22131 lines...]
===
[GC 715984K->480455K(759296K), 0.0160060 secs]
Tests run: 2029, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 184.177 sec 
<<< FAILURE! - in TestSuite
(org.apache.brooklyn.core.entity.ApplicationLifecycleStateTest)  Time elapsed: 
0.073 sec  <<< FAILURE!
java.lang.AssertionError: entity=Application[am49yx1t]; attribute=Sensor: 
service.state (org.apache.brooklyn.core.entity.lifecycle.Lifecycle) expected 
[running] but found [on-fire]
at 
org.apache.brooklyn.core.entity.ApplicationLifecycleStateTest.assertHealthContinually(ApplicationLifecycleStateTest.java:196)
at 
org.apache.brooklyn.core.entity.ApplicationLifecycleStateTest.testStartsThenChildFailsButWithQuorumCausesAppToSucceed(ApplicationLifecycleStateTest.java:170)

2017-02-15 14:48:55,388 INFO  Brooklyn shutdown: stopping entities 
[TestEntityImpl{id=v5eozz824h}, TestEntityImpl{id=ml710c2kww}, 
BlockingEntityImpl{id=bh630kzzz7}]

Results :

Failed tests: 
org.apache.brooklyn.core.entity.ApplicationLifecycleStateTest.(org.apache.brooklyn.core.entity.ApplicationLifecycleStateTest)
  Run 1: PASS
  Run 2: PASS
  Run 3: PASS
  Run 4: PASS
  Run 5: PASS
  Run 6: PASS
  Run 7: PASS
  Run 8: 
ApplicationLifecycleStateTest.testStartsThenChildFailsButWithQuorumCausesAppToSucceed:170->assertHealthContinually:196
 entity=Application[am49yx1t]; attribute=Sensor: service.state 
(org.apache.brooklyn.core.entity.lifecycle.Lifecycle) expected [running] but 
found [on-fire]
  Run 9: PASS
  Run 10: PASS


Tests run: 2020, Failures: 1, Errors: 0, Skipped: 0

[JENKINS] Recording test results
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Brooklyn REST JavaScript Web GUI ... SUCCESS [01:23 min]
[INFO] Brooklyn Server Root ... SUCCESS [  1.141 s]
[INFO] Brooklyn Parent Project  SUCCESS [  5.048 s]
[INFO] Brooklyn Test Support Utilities  SUCCESS [  8.072 s]
[INFO] Brooklyn Logback Includable Configuration .. SUCCESS [  4.190 s]
[INFO] Brooklyn Common Utilities .. SUCCESS [ 29.107 s]
[INFO] Brooklyn API ... SUCCESS [  6.129 s]
[INFO] CAMP Server Parent Project . SUCCESS [  2.495 s]
[INFO] CAMP Base .. SUCCESS [  7.282 s]
[INFO] Brooklyn Test Support .. SUCCESS [  4.788 s]
[INFO] Brooklyn REST Swagger Apidoc Utilities . SUCCESS [  5.902 s]
[INFO] Brooklyn Logback Configuration . SUCCESS [  3.936 s]
[INFO] CAMP Server  SUCCESS [  8.909 s]
[INFO] Brooklyn Felix Runtime . SUCCESS [  6.847 s]
[INFO] Brooklyn Groovy Utilities .. SUCCESS [  6.497 s]
[INFO] Brooklyn Core .. FAILURE [03:45 min]
[INFO] Brooklyn Policies .. SKIPPED
[INFO] Brooklyn WinRM Software Entities ... SKIPPED
[INFO] Brooklyn Secure JMXMP Agent  SKIPPED
[INFO] Brooklyn JMX RMI Agent . SKIPPED
[INFO] Brooklyn Jclouds Location Targets .. SKIPPED
[INFO] Brooklyn Software Base . SKIPPED
[INFO] Brooklyn CAMP .. SKIPPED
[INFO] Brooklyn Hazelcast Storage . SKIPPED
[INFO] Brooklyn Launcher Common ... SKIPPED
[INFO] Brooklyn REST API .. SKIPPED
[INFO] Brooklyn REST Resources  SKIPPED
[INFO] Brooklyn REST Server ... SKIPPED
[INFO] Brooklyn Launcher .. SKIPPED
[INFO] Brooklyn Command Line Interface  SKIPPED
[INFO] Brooklyn Test Framework  SKIPPED
[INFO] Brooklyn OSGi init . SKIPPED
[INFO] Brooklyn Karaf . SKIPPED
[INFO] Jetty config fragment .. SKIPPED
[INFO] Apache Http Component extension  SKIPPED
[INFO] Brooklyn Karaf Features  SKIPPED
[INFO] Brooklyn Karaf Shell Commands .. SKIPPED
[INFO] Brooklyn Library Root .. SKIPPED
[INFO] Brooklyn CM SaltStack .. SKIPPED
[INFO] Brooklyn CM Ansible  SKIPPED
[INFO] Brooklyn CM Integration Root ... SKIPPED
[INFO] Brooklyn Network Software Entities . SKIPPED
[INFO] Brooklyn OSGi Software Entities  SKIPPED
[INFO] 

Re: [DISCUSSION] Determining which Brooklyn node address to advertise

[Sam Corbett]

Thanks for clarifying. It was this cross-cloud case I was considering.

What is the benefit of the "management-private-" group? It 
seems superfluous to me if "management-private-ingress-" will 
contain the public IPs of the members of the cluster.



On 15/02/2017 14:16, Svetoslav Neykov wrote:

My response below was based on my thinking about in-cloud access between 
Brooklyn and the managed machines.
When the access is cross-cloud we indeed need _c_ security groups. Each one 
containing _n_ records with the public IPs of the HA cluster members. These can 
be managed by Brooklyn though.

To summarise (and get my thinking straight). In each cloud/availability zone we 
could have:
 1. "management-private-" SG assigned on the HA cluster member 
machines. No records in the SG.
 2. "management-private-ingress-" SG with first record allowing all traffic from 
"management-private-" (above group) and _n_ more records allowing all traffic coming 
from the public IPs of the HA member nodes. This one is assigned to all managed entities.

On adding a new member to the cluster:
   1. Assign "management-private-" to the new machine - this is the 
only action that needs to be done by the manager of the cluster
   2. Go to each cloud and update the "management-private-ingress-" 
group, adding the new public IP.

Svet.



On 15.02.2017 г., at 15:40, Svetoslav Neykov 
 wrote:


You propose that the manager of the Brooklyn HA cluster maintain at least _c_ 
security groups (one per security group scope - e.g. AWS EC2 region - per 
cloud).

Not quite. It's the number of "clouds HA cluster is deployed to". That's the 
number of availability zones - usually a low number 1-2-3.


Each of these groups has _n_ records. When the HA cluster is resized each group 
is modified to add or remove a record as appropriate.

No, they are empty. Adding a new cluster member is just assigning the SG to the 
new machine. Then for each managed entity there's a record in its security 
group to allow traffic from the HA security group.
For clouds where there are no running HA cluster members Brooklyn will 
auto-create the security group and add it to entities' security groups but it 
will be unused.

The manager of the HA cluster can wait for Brooklyn to create the "management" 
SG (which will contain the cluster ID in its name which is not known in advance) and then 
assign it to the HA cluster members or create one with a predefined name and configure 
the name in each HA instance.

Svet.




On 15.02.2017 г., at 14:59, Sam Corbett  wrote:

Interesting problem Svet. Your proposal is a neat way of sidestepping the 
problem of updating many security groups as the set of HA nodes changes.

Let me rephrase it to see if I understand correctly.

Suppose we have:
* _n_ Brooklyn servers in an HA cluster (that could be across many clouds / 
regions within a cloud)
* _c_ clouds that Brooklyn can deploy to
* _m_ instances across those clouds.

We want to avoid the n+1th Brooklyn node requiring _m_ security group updates.

You propose that the manager of the Brooklyn HA cluster maintain at least _c_ 
security groups (one per security group scope - e.g. AWS EC2 region - per 
cloud). Each of these groups has _n_ records. When the HA cluster is resized 
each group is modified to add or remove a record as appropriate.

Do I have this correct?

Sam


On 14/02/2017 15:42, Svetoslav Neykov wrote:

I'm trying to restrict access to the machines managed by Brooklyn using security groups - 
tightening jclouds' default behaviour of opening the "inboundPorts" to any 
source.
Brooklyn obviously needs to have access to all managed machines. This means it 
needs to figure out the address it uses to access each machine and white list 
it in the machine's security group.
This is kind of related to the email thread "[PROPOSAL] Separate management 
addresses from the concept of an entity's public address" [1], but in reverse. 
Instead of figuring out which machine IP to use I need to do the reverse - which Brooklyn 
node IP will access the machine.
It becomes more complicated when HA is introduced into the mix. Any node that 
becomes a master needs to be able to access the machines. This means the 
security groups need to be updated in such cases.

Two questions follow:
  1. How to determine which IP faces managed machines? There's no one fixed 
answer here. Depending on the target cloud and location configuration it varies.
  2. How to keep the list of IPs from above point in sync, for each of the 
members of the HA cluster?

Don't think we can actually answer q1. That's why the solution I'm thinking of 
is:
  * Always open the external IP to the machines. The external IP is as reported by 
"LocalhostExternalIpLoader".
  * Assign a predefined SG to all machines in the HA cluster - manually/out of band, since the 
machines are not managed by Brooklyn. Let Brooklyn know the SG name, defaulting to 

Re: [DISCUSSION] Determining which Brooklyn node address to advertise

[Svetoslav Neykov]

My response below was based on my thinking about in-cloud access between 
Brooklyn and the managed machines.
When the access is cross-cloud we indeed need _c_ security groups. Each one 
containing _n_ records with the public IPs of the HA cluster members. These can 
be managed by Brooklyn though.

To summarise (and get my thinking straight). In each cloud/availability zone we 
could have:
1. "management-private-" SG assigned on the HA cluster member 
machines. No records in the SG.
2. "management-private-ingress-" SG with first record allowing 
all traffic from "management-private-" (above group) and _n_ more 
records allowing all traffic coming from the public IPs of the HA member nodes. 
This one is assigned to all managed entities.

On adding a new member to the cluster:
  1. Assign "management-private-" to the new machine - this is the 
only action that needs to be done by the manager of the cluster
  2. Go to each cloud and update the "management-private-ingress-" 
group, adding the new public IP.

Svet.


> On 15.02.2017 г., at 15:40, Svetoslav Neykov 
>  wrote:
> 
>> You propose that the manager of the Brooklyn HA cluster maintain at least 
>> _c_ security groups (one per security group scope - e.g. AWS EC2 region - 
>> per cloud).
> 
> Not quite. It's the number of "clouds HA cluster is deployed to". That's the 
> number of availability zones - usually a low number 1-2-3.
> 
>> Each of these groups has _n_ records. When the HA cluster is resized each 
>> group is modified to add or remove a record as appropriate.
> 
> No, they are empty. Adding a new cluster member is just assigning the SG to 
> the new machine. Then for each managed entity there's a record in its 
> security group to allow traffic from the HA security group.
> For clouds where there are no running HA cluster members Brooklyn will 
> auto-create the security group and add it to entities' security groups but it 
> will be unused.
> 
> The manager of the HA cluster can wait for Brooklyn to create the 
> "management" SG (which will contain the cluster ID in its name which is not 
> known in advance) and then assign it to the HA cluster members or create one 
> with a predefined name and configure the name in each HA instance.
> 
> Svet.
> 
> 
> 
>> On 15.02.2017 г., at 14:59, Sam Corbett  
>> wrote:
>> 
>> Interesting problem Svet. Your proposal is a neat way of sidestepping the 
>> problem of updating many security groups as the set of HA nodes changes.
>> 
>> Let me rephrase it to see if I understand correctly.
>> 
>> Suppose we have:
>> * _n_ Brooklyn servers in an HA cluster (that could be across many clouds / 
>> regions within a cloud)
>> * _c_ clouds that Brooklyn can deploy to
>> * _m_ instances across those clouds.
>> 
>> We want to avoid the n+1th Brooklyn node requiring _m_ security group 
>> updates.
>> 
>> You propose that the manager of the Brooklyn HA cluster maintain at least 
>> _c_ security groups (one per security group scope - e.g. AWS EC2 region - 
>> per cloud). Each of these groups has _n_ records. When the HA cluster is 
>> resized each group is modified to add or remove a record as appropriate.
>> 
>> Do I have this correct?
>> 
>> Sam
>> 
>> 
>> On 14/02/2017 15:42, Svetoslav Neykov wrote:
>>> I'm trying to restrict access to the machines managed by Brooklyn using 
>>> security groups - tightening jclouds' default behaviour of opening the 
>>> "inboundPorts" to any source.
>>> Brooklyn obviously needs to have access to all managed machines. This means 
>>> it needs to figure out the address it uses to access each machine and white 
>>> list it in the machine's security group.
>>> This is kind of related to the email thread "[PROPOSAL] Separate management 
>>> addresses from the concept of an entity's public address" [1], but in 
>>> reverse. Instead of figuring out which machine IP to use I need to do the 
>>> reverse - which Brooklyn node IP will access the machine.
>>> It becomes more complicated when HA is introduced into the mix. Any node 
>>> that becomes a master needs to be able to access the machines. This means 
>>> the security groups need to be updated in such cases.
>>> 
>>> Two questions follow:
>>>  1. How to determine which IP faces managed machines? There's no one fixed 
>>> answer here. Depending on the target cloud and location configuration it 
>>> varies.
>>>  2. How to keep the list of IPs from above point in sync, for each of the 
>>> members of the HA cluster?
>>> 
>>> Don't think we can actually answer q1. That's why the solution I'm thinking 
>>> of is:
>>>  * Always open the external IP to the machines. The external IP is as 
>>> reported by "LocalhostExternalIpLoader".
>>>  * Assign a predefined SG to all machines in the HA cluster - manually/out 
>>> of band, since the machines are not managed by Brooklyn. Let Brooklyn know 
>>> the SG name, defaulting to "management-". White list the SG as 
>>> a source 

[GitHub] brooklyn-server pull request #559: Activity api include background

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: [DISCUSSION] Determining which Brooklyn node address to advertise

[Svetoslav Neykov]

> You propose that the manager of the Brooklyn HA cluster maintain at least _c_ 
> security groups (one per security group scope - e.g. AWS EC2 region - per 
> cloud).

Not quite. It's the number of "clouds HA cluster is deployed to". That's the 
number of availability zones - usually a low number 1-2-3.

> Each of these groups has _n_ records. When the HA cluster is resized each 
> group is modified to add or remove a record as appropriate.

No, they are empty. Adding a new cluster member is just assigning the SG to the 
new machine. Then for each managed entity there's a record in its security 
group to allow traffic from the HA security group.
For clouds where there are no running HA cluster members Brooklyn will 
auto-create the security group and add it to entities' security groups but it 
will be unused.

The manager of the HA cluster can wait for Brooklyn to create the "management" 
SG (which will contain the cluster ID in its name which is not known in 
advance) and then assign it to the HA cluster members or create one with a 
predefined name and configure the name in each HA instance.

Svet.



> On 15.02.2017 г., at 14:59, Sam Corbett  wrote:
> 
> Interesting problem Svet. Your proposal is a neat way of sidestepping the 
> problem of updating many security groups as the set of HA nodes changes.
> 
> Let me rephrase it to see if I understand correctly.
> 
> Suppose we have:
> * _n_ Brooklyn servers in an HA cluster (that could be across many clouds / 
> regions within a cloud)
> * _c_ clouds that Brooklyn can deploy to
> * _m_ instances across those clouds.
> 
> We want to avoid the n+1th Brooklyn node requiring _m_ security group updates.
> 
> You propose that the manager of the Brooklyn HA cluster maintain at least _c_ 
> security groups (one per security group scope - e.g. AWS EC2 region - per 
> cloud). Each of these groups has _n_ records. When the HA cluster is resized 
> each group is modified to add or remove a record as appropriate.
> 
> Do I have this correct?
> 
> Sam
> 
> 
> On 14/02/2017 15:42, Svetoslav Neykov wrote:
>> I'm trying to restrict access to the machines managed by Brooklyn using 
>> security groups - tightening jclouds' default behaviour of opening the 
>> "inboundPorts" to any source.
>> Brooklyn obviously needs to have access to all managed machines. This means 
>> it needs to figure out the address it uses to access each machine and white 
>> list it in the machine's security group.
>> This is kind of related to the email thread "[PROPOSAL] Separate management 
>> addresses from the concept of an entity's public address" [1], but in 
>> reverse. Instead of figuring out which machine IP to use I need to do the 
>> reverse - which Brooklyn node IP will access the machine.
>> It becomes more complicated when HA is introduced into the mix. Any node 
>> that becomes a master needs to be able to access the machines. This means 
>> the security groups need to be updated in such cases.
>> 
>> Two questions follow:
>>   1. How to determine which IP faces managed machines? There's no one fixed 
>> answer here. Depending on the target cloud and location configuration it 
>> varies.
>>   2. How to keep the list of IPs from above point in sync, for each of the 
>> members of the HA cluster?
>> 
>> Don't think we can actually answer q1. That's why the solution I'm thinking 
>> of is:
>>   * Always open the external IP to the machines. The external IP is as 
>> reported by "LocalhostExternalIpLoader".
>>   * Assign a predefined SG to all machines in the HA cluster - manually/out 
>> of band, since the machines are not managed by Brooklyn. Let Brooklyn know 
>> the SG name, defaulting to "management-". White list the SG as a 
>> source for all managed machines. This will allow Brooklyn to access managed 
>> machines on both the public and private IPs. It moves the responsibility of 
>> assigning the SG to new HA member machines to whoever is managing the 
>> Brooklyn cluster. We could then update the management SG with **all** 
>> private IPs in the HA cluster (need to advertise them in the meta data) or 
>> leave it again to the manager of the cluster.
>> 
>> Would be really cool to have HA clusters manage/heal themselves.
>> 
>> Tangentially related - [2] which IP do we use for the "url" field int he HA 
>> member nodes metadata in REST API (currently empty for the Karaf dist). If 
>> it's always the public IP then it doesn't work for private/VPN instances. 
>> It is important for this to be the right one because:
>>   * Users are redirected to the master node
>>   * Automated systems need to know which is the current master. On failover 
>> the old master (if still around) will redirect to the new master. Workaround 
>> is to keep a local copy of the HA members and iterate over them until it 
>> hits MASTER - but it's still important that the URLs are accessible.
>> 
>> Svet
>> 
>> [1] 
>> 

[GitHub] brooklyn-server issue #559: Activity api include background

[tbouron]

Github user tbouron commented on the issue:

https://github.com/apache/brooklyn-server/pull/559
  
Thanks @ahgittin! Tested works great, LGTM.

PS: Jenkins failure looks unrelated:
```

testCleanedCopiedPersistedState(org.apache.brooklyn.launcher.CleanOrphanedLocationsIntegrationTest)
  Time elapsed: 0.11 sec  <<< FAILURE!
java.lang.AssertionError
at 
org.apache.brooklyn.launcher.CleanOrphanedLocationsIntegrationTest.testCleanedCopiedPersistedState(CleanOrphanedLocationsIntegrationTest.java:167)


testSelectionWithOrphanedLocationsInData(org.apache.brooklyn.launcher.CleanOrphanedLocationsIntegrationTest)
  Time elapsed: 0.025 sec  <<< FAILURE!
java.lang.AssertionError: expected [true] but found [false]
at 
org.apache.brooklyn.launcher.CleanOrphanedLocationsIntegrationTest.testSelectionWithOrphanedLocationsInData(CleanOrphanedLocationsIntegrationTest.java:136)

2017-02-15 12:21:30,290 INFO  Brooklyn shutdown: stopping entities 
[Application[wi9i9uod], Application[3pl879q6], 
BasicApplicationImpl{id=qqh8wj4nom}, Application[ymh6lc97], 
Application[n1o06am3]]
```


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

Jenkins build is back to normal : brooklyn-master-build #829

[Apache Jenkins Server]

See 

Re: [DISCUSSION] Determining which Brooklyn node address to advertise

[Sam Corbett]

Interesting problem Svet. Your proposal is a neat way of sidestepping 
the problem of updating many security groups as the set of HA nodes 
changes.


Let me rephrase it to see if I understand correctly.

Suppose we have:
* _n_ Brooklyn servers in an HA cluster (that could be across many 
clouds / regions within a cloud)

* _c_ clouds that Brooklyn can deploy to
* _m_ instances across those clouds.

We want to avoid the n+1th Brooklyn node requiring _m_ security group 
updates.


You propose that the manager of the Brooklyn HA cluster maintain at 
least _c_ security groups (one per security group scope - e.g. AWS EC2 
region - per cloud). Each of these groups has _n_ records. When the HA 
cluster is resized each group is modified to add or remove a record as 
appropriate.


Do I have this correct?

Sam


On 14/02/2017 15:42, Svetoslav Neykov wrote:

I'm trying to restrict access to the machines managed by Brooklyn using security groups - 
tightening jclouds' default behaviour of opening the "inboundPorts" to any 
source.
Brooklyn obviously needs to have access to all managed machines. This means it 
needs to figure out the address it uses to access each machine and white list 
it in the machine's security group.
This is kind of related to the email thread "[PROPOSAL] Separate management 
addresses from the concept of an entity's public address" [1], but in reverse. 
Instead of figuring out which machine IP to use I need to do the reverse - which Brooklyn 
node IP will access the machine.
It becomes more complicated when HA is introduced into the mix. Any node that 
becomes a master needs to be able to access the machines. This means the 
security groups need to be updated in such cases.

Two questions follow:
   1. How to determine which IP faces managed machines? There's no one fixed 
answer here. Depending on the target cloud and location configuration it varies.
   2. How to keep the list of IPs from above point in sync, for each of the 
members of the HA cluster?

Don't think we can actually answer q1. That's why the solution I'm thinking of 
is:
   * Always open the external IP to the machines. The external IP is as reported by 
"LocalhostExternalIpLoader".
   * Assign a predefined SG to all machines in the HA cluster - manually/out of band, since the 
machines are not managed by Brooklyn. Let Brooklyn know the SG name, defaulting to 
"management-". White list the SG as a source for all managed 
machines. This will allow Brooklyn to access managed machines on both the public and private 
IPs. It moves the responsibility of assigning the SG to new HA member machines to whoever is 
managing the Brooklyn cluster. We could then update the management SG with **all** private IPs 
in the HA cluster (need to advertise them in the meta data) or leave it again to the manager of 
the cluster.

Would be really cool to have HA clusters manage/heal themselves.

Tangentially related - [2] which IP do we use for the "url" field int he HA 
member nodes metadata in REST API (currently empty for the Karaf dist). If it's always 
the public IP then it doesn't work for private/VPN instances. It is important for this 
to be the right one because:
   * Users are redirected to the master node
   * Automated systems need to know which is the current master. On failover 
the old master (if still around) will redirect to the new master. Workaround is 
to keep a local copy of the HA members and iterate over them until it hits 
MASTER - but it's still important that the URLs are accessible.

Svet

[1] 
https://lists.apache.org/list.html?dev@brooklyn.apache.org:lte=1y:%5BPROPOSAL%5D%20Separate%20management%20addresses%20from%20the%20concept%20of%20an%20entity%27s%20public%20address
[2] https://issues.apache.org/jira/browse/BROOKLYN-436

entity/.../activities endpoint minor API change for background tasks

[Alex Heneveld]

Hi All-

In [1], @tbouron and I add an "includeBackground" query parameter to the 
`/activities//children` endpoint.  This is useful as you can see 
which tasks were "submitted by" the given task, even if they aren't 
explicit sub-tasks.  Typically these are less interesting eg message 
delivery, resolving config, etc -- but sometimes they are useful to 
see.  IE "opt-in" semantics feels right, which is what we have added.  
(Previously this API endpoint didn't even offer it as an option.  NB it 
still restricts to those running on the current entity, for efficiency 
reasons, so if you want to see tasks crossing entity boundaries in the 
UI they *must* be done as subtasks, ie to a DynamicSequentialTask rather 
than a BasicTask.)


It is inconsistent however with `/entities//activities`  which 
includes *all* tasks running at an entity.  Most of the time, at least 
in the UI, we are interested in the _top level_ tasks, IE those which 
either are not submitted by a task (eg effector), or those which are 
submitted by a task in a different entity (cross-entity tasks).  
Currently however we get all the tasks submitted by any such tasks, 
recursively, subtasks and background tasks, etc, as long as they are 
running on the entity.  (Filtering this is how we populate background 
tasks above!)


I think we should change this, either:

(1) change `/entities//activities` to return top-level tasks only, 
unless `?includeBackground=true` is specified in which case it will 
return all tasks on the entity (eg previous behaviour)


(2) leave `/entities//activities` as is, but allow 
`?topLevelOnly=true` to filter out those submitted by tasks on the 
current entity


I think (1) is more intuitive (extra parameter to get extra less 
commonly wanted info) and in line with the `/entities/xxx/activities` 
endpoint.  However it changes the REST API.  I think it is acceptable as 
most places right now the behaviour of (1) causes "bugs" in a UI -- eg 
seeing lots of blank tasks since bg tasks often don't have a name.  But 
if we want to be strict then (2) is the way to go.


Thoughts?

Best
Alex




[1] https://github.com/apache/brooklyn-server/pull/559

[GitHub] brooklyn-server pull request #521: fix unexpected AddChildrenEffector behavi...

[asfgit]

Github user asfgit closed the pull request at:

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


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

Build failed in Jenkins: brooklyn-master-build #828

[Apache Jenkins Server]

See 

--
[...truncated 22129 lines...]
Tests run: 2029, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 181.453 sec 
<<< FAILURE! - in TestSuite
(org.apache.brooklyn.core.entity.ApplicationLifecycleStateTest)  Time elapsed: 
0.073 sec  <<< FAILURE!
java.lang.AssertionError: entity=Application[f7rq8kxx]; attribute=Sensor: 
service.state (org.apache.brooklyn.core.entity.lifecycle.Lifecycle) expected 
[running] but found [on-fire]
at 
org.apache.brooklyn.core.entity.ApplicationLifecycleStateTest.assertHealthContinually(ApplicationLifecycleStateTest.java:196)
at 
org.apache.brooklyn.core.entity.ApplicationLifecycleStateTest.testStartsThenChildFailsButWithQuorumCausesAppToSucceed(ApplicationLifecycleStateTest.java:170)

2017-02-15 11:40:34,023 INFO  Brooklyn shutdown: stopping entities 
[TestEntityImpl{id=ws11brj0li}, TestEntityImpl{id=gvsr4b0oaa}, 
BlockingEntityImpl{id=kfkinewynf}]

Results :

Failed tests: 
org.apache.brooklyn.core.entity.ApplicationLifecycleStateTest.(org.apache.brooklyn.core.entity.ApplicationLifecycleStateTest)
  Run 1: PASS
  Run 2: PASS
  Run 3: PASS
  Run 4: PASS
  Run 5: PASS
  Run 6: PASS
  Run 7: PASS
  Run 8: 
ApplicationLifecycleStateTest.testStartsThenChildFailsButWithQuorumCausesAppToSucceed:170->assertHealthContinually:196
 entity=Application[f7rq8kxx]; attribute=Sensor: service.state 
(org.apache.brooklyn.core.entity.lifecycle.Lifecycle) expected [running] but 
found [on-fire]
  Run 9: PASS
  Run 10: PASS


Tests run: 2020, Failures: 1, Errors: 0, Skipped: 0

[JENKINS] Recording test results
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Brooklyn REST JavaScript Web GUI ... SUCCESS [01:21 min]
[INFO] Brooklyn Server Root ... SUCCESS [  1.102 s]
[INFO] Brooklyn Parent Project  SUCCESS [  5.030 s]
[INFO] Brooklyn Test Support Utilities  SUCCESS [ 10.120 s]
[INFO] Brooklyn Logback Includable Configuration .. SUCCESS [  4.564 s]
[INFO] Brooklyn Common Utilities .. SUCCESS [ 27.078 s]
[INFO] Brooklyn API ... SUCCESS [  4.885 s]
[INFO] CAMP Server Parent Project . SUCCESS [  2.404 s]
[INFO] CAMP Base .. SUCCESS [  8.832 s]
[INFO] Brooklyn Test Support .. SUCCESS [  4.621 s]
[INFO] Brooklyn REST Swagger Apidoc Utilities . SUCCESS [  4.980 s]
[INFO] Brooklyn Logback Configuration . SUCCESS [  3.913 s]
[INFO] CAMP Server  SUCCESS [  8.763 s]
[INFO] Brooklyn Felix Runtime . SUCCESS [  8.523 s]
[INFO] Brooklyn Groovy Utilities .. SUCCESS [  7.052 s]
[INFO] Brooklyn Core .. FAILURE [03:38 min]
[INFO] Brooklyn Policies .. SKIPPED
[INFO] Brooklyn WinRM Software Entities ... SKIPPED
[INFO] Brooklyn Secure JMXMP Agent  SKIPPED
[INFO] Brooklyn JMX RMI Agent . SKIPPED
[INFO] Brooklyn Jclouds Location Targets .. SKIPPED
[INFO] Brooklyn Software Base . SKIPPED
[INFO] Brooklyn CAMP .. SKIPPED
[INFO] Brooklyn Hazelcast Storage . SKIPPED
[INFO] Brooklyn Launcher Common ... SKIPPED
[INFO] Brooklyn REST API .. SKIPPED
[INFO] Brooklyn REST Resources  SKIPPED
[INFO] Brooklyn REST Server ... SKIPPED
[INFO] Brooklyn Launcher .. SKIPPED
[INFO] Brooklyn Command Line Interface  SKIPPED
[INFO] Brooklyn Test Framework  SKIPPED
[INFO] Brooklyn OSGi init . SKIPPED
[INFO] Brooklyn Karaf . SKIPPED
[INFO] Jetty config fragment .. SKIPPED
[INFO] Apache Http Component extension  SKIPPED
[INFO] Brooklyn Karaf Features  SKIPPED
[INFO] Brooklyn Karaf Shell Commands .. SKIPPED
[INFO] Brooklyn Library Root .. SKIPPED
[INFO] Brooklyn CM SaltStack .. SKIPPED
[INFO] Brooklyn CM Ansible  SKIPPED
[INFO] Brooklyn CM Integration Root ... SKIPPED
[INFO] Brooklyn Network Software Entities . SKIPPED
[INFO] Brooklyn OSGi Software Entities  SKIPPED
[INFO] Brooklyn Database Software Entities  SKIPPED
[INFO] Brooklyn Web App Software 

[GitHub] brooklyn-server pull request #516: Add unit tests for Karaf features

[m4rkmckenna]

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

https://github.com/apache/brooklyn-server/pull/516#discussion_r101255832
  
--- Diff: karaf/features/src/main/feature/feature.xml ---
@@ -260,7 +260,7 @@
 https://github.com/square/okhttp/pull/2246
 -->
 
-wrap:mvn:com.squareup.okhttp/okhttp/2.2.0$Import-Package=org.apache.http.*;resolution:=optional,android.util.*;resolution:=optional,okio;version=%27[1.2.0,1.3.0)%27,*
+mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.okhttp/2.2.0_2
--- End diff --

Can you explain your reasoning for this ... I remember there being an issue 
with the servicemix wrapped version

Also version should be parameterised 


---
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-server pull request #516: Add unit tests for Karaf features

[m4rkmckenna]

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

https://github.com/apache/brooklyn-server/pull/516#discussion_r101255259
  
--- Diff: karaf/itests/pom.xml ---
@@ -0,0 +1,180 @@
+
+
+http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
+ xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
+
+4.0.0
+
+org.apache.brooklyn
+brooklyn-karaf
+0.11.0-SNAPSHOT  
+
+
+brooklyn-features-itests
+Brooklyn Karaf Tests
+
+
+6.0.0
+4.9.1
+2.5.2
+3.1.0
+1.1.0.Final
+
+
+
+
+org.apache.brooklyn
+brooklyn-core
+${project.version}
+
+
+org.osgi
+org.osgi.core
+${osgi.version}
+test
+
+
+
+org.apache.karaf.itests
+itests
+${karaf.version}
+test-jar
+test
+
+
+
+org.apache.karaf
+apache-karaf
+${karaf.version}
+test
+tar.gz
+
+
+org.apache.karaf.client
+org.apache.karaf
+
+
+
+
+
+org.ops4j.pax.exam
+pax-exam-container-karaf
+${pax.exam.version}
+test
+
+
+org.ops4j.pax.exam
+pax-exam-container-karaf
+${pax.exam.version}
+test
+
+
+
+org.ops4j.pax.exam
+pax-exam-junit4
+${pax.exam.version}
+test
+
+
+
+org.apache.geronimo.specs
+geronimo-atinject_1.0_spec
+1.0
+test
+
+
+
+
+
+
+org.apache.servicemix.tooling
+depends-maven-plugin
+1.3
--- End diff --

Should be parameterised 


---
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-server pull request #516: Add unit tests for Karaf features

[m4rkmckenna]

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

https://github.com/apache/brooklyn-server/pull/516#discussion_r101255165
  
--- Diff: karaf/itests/pom.xml ---
@@ -0,0 +1,180 @@
+
+
+http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
+ xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
+
+4.0.0
+
+org.apache.brooklyn
+brooklyn-karaf
+0.11.0-SNAPSHOT  
+
+
+brooklyn-features-itests
+Brooklyn Karaf Tests
+
+
+6.0.0
+4.9.1
+2.5.2
+3.1.0
+1.1.0.Final
--- End diff --

Can you move these to the parent pom


---
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-server issue #557: transfer icons from catalog items to entities

[drigodwin]

Github user drigodwin commented on the issue:

https://github.com/apache/brooklyn-server/pull/557
  
This looks fine, what are the sources and licenses of the icons @ahgittin?


---
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-server issue #557: transfer icons from catalog items to entities

[drigodwin]

Github user drigodwin commented on the issue:

https://github.com/apache/brooklyn-server/pull/557
  
This looks fine, what are the sources and licenses of the icons @ahgittin?


---
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-server pull request #558: BROOKLYN-433: regex/obj config key constr...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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] [Commented] (BROOKLYN-433) YAML-based config constraint to support regex

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on BROOKLYN-433:
-

Github user asfgit closed the pull request at:

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


> YAML-based config constraint to support regex
> -
>
> Key: BROOKLYN-433
> URL: https://issues.apache.org/jira/browse/BROOKLYN-433
> Project: Brooklyn
>  Issue Type: Improvement
>Affects Versions: 0.10.0
>Reporter: Aled Sage
>Assignee: Aled Sage
>Priority: Minor
>
> One can specify constraints on a config key's value, to give a validation 
> error if an invalid value is supplied.
> In the Java code, this can be any predicate.
> However, in YAML we don't support many options. It would be good to support a 
> regex constraint. For example:
> {noformat}
> brooklyn.parameters:
> - name: address
>   type: string
>   constraints:
>   - required
>   - regex: ^(?:[0-9]{1,3}\.){3}[0-9]{1,3}$
> {noformat}
> See docs at 
> https://raw.githubusercontent.com/apache/brooklyn-docs/master/guide/yaml/yaml-reference.md,
>  and code at 
> https://github.com/apache/brooklyn-server/blob/master/core/src/main/java/org/apache/brooklyn/core/objs/BasicSpecParameter.java#L204-L205



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

Build failed in Jenkins: brooklyn-master-build #827

[Apache Jenkins Server]

See 

--
[...truncated 2050 lines...]
2017-02-15 09:39:24,763 INFO  TESTNG PASSED: "Surefire test" - 
org.apache.brooklyn.util.text.QuotedStringTokenizerTest.testQuoting() finished 
in 1 ms
2017-02-15 09:39:24,763 INFO  TESTNG INVOKING: "Surefire test" - 
org.apache.brooklyn.util.text.QuotedStringTokenizerTest.testTokenizing()
2017-02-15 09:39:24,764 INFO  TESTNG PASSED: "Surefire test" - 
org.apache.brooklyn.util.text.QuotedStringTokenizerTest.testTokenizing() 
finished in 1 ms
2017-02-15 09:39:24,764 INFO  TESTNG INVOKING: "Surefire test" - 
org.apache.brooklyn.util.text.QuotedStringTokenizerTest.testTokenizingBuilder()
2017-02-15 09:39:24,764 INFO  TESTNG PASSED: "Surefire test" - 
org.apache.brooklyn.util.text.QuotedStringTokenizerTest.testTokenizingBuilder() 
finished in 0 ms
2017-02-15 09:39:24,765 INFO  TESTNG INVOKING: "Surefire test" - 
org.apache.brooklyn.util.text.StringPredicatesTest.testContainsLiteral()
2017-02-15 09:39:24,765 INFO  TESTNG PASSED: "Surefire test" - 
org.apache.brooklyn.util.text.StringPredicatesTest.testContainsLiteral() 
finished in 0 ms
2017-02-15 09:39:24,765 INFO  TESTNG INVOKING: "Surefire test" - 
org.apache.brooklyn.util.text.StringPredicatesTest.testEqualToAny()
2017-02-15 09:39:24,766 INFO  TESTNG PASSED: "Surefire test" - 
org.apache.brooklyn.util.text.StringPredicatesTest.testEqualToAny() finished in 
1 ms
2017-02-15 09:39:24,766 INFO  TESTNG INVOKING: "Surefire test" - 
org.apache.brooklyn.util.text.StringPredicatesTest.testIsBlank()
2017-02-15 09:39:24,767 INFO  TESTNG PASSED: "Surefire test" - 
org.apache.brooklyn.util.text.StringPredicatesTest.testIsBlank() finished in 1 
ms
2017-02-15 09:39:24,767 INFO  TESTNG INVOKING: "Surefire test" - 
org.apache.brooklyn.util.text.StringPredicatesTest.testMatches()
2017-02-15 09:39:24,768 INFO  TESTNG PASSED: "Surefire test" - 
org.apache.brooklyn.util.text.StringPredicatesTest.testMatches() finished in 1 
ms
2017-02-15 09:39:24,768 INFO  TESTNG INVOKING: "Surefire test" - 
org.apache.brooklyn.util.text.StringPredicatesTest.testStartsWith()
2017-02-15 09:39:24,769 INFO  TESTNG PASSED: "Surefire test" - 
org.apache.brooklyn.util.text.StringPredicatesTest.testStartsWith() finished in 
1 ms
2017-02-15 09:39:24,769 INFO  TESTNG INVOKING: "Surefire test" - 
org.apache.brooklyn.util.JavaGroovyEquivalentsTest.testElvis()
2017-02-15 09:39:24,770 INFO  TESTNG PASSED: "Surefire test" - 
org.apache.brooklyn.util.JavaGroovyEquivalentsTest.testElvis() finished in 1 ms
2017-02-15 09:39:24,770 INFO  TESTNG INVOKING: "Surefire test" - 
org.apache.brooklyn.util.JavaGroovyEquivalentsTest.testTruth()
2017-02-15 09:39:24,771 INFO  TESTNG PASSED: "Surefire test" - 
org.apache.brooklyn.util.JavaGroovyEquivalentsTest.testTruth() finished in 1 ms
2017-02-15 09:39:24,771 INFO  TESTNG INVOKING: "Surefire test" - 
org.apache.brooklyn.test.AssertsTest.testAssertReturnsEventually()
2017-02-15 09:39:24,772 INFO  TESTNG PASSED: "Surefire test" - 
org.apache.brooklyn.test.AssertsTest.testAssertReturnsEventually() finished in 
1 ms
2017-02-15 09:39:24,772 INFO  TESTNG INVOKING: "Surefire test" - 
org.apache.brooklyn.test.AssertsTest.testAssertReturnsEventuallyPropagatesException()
Exception in thread 
"assertReturnsEventually(org.apache.brooklyn.test.AssertsTest$4@3fc080c2)" 
java.lang.IllegalStateException: Simulating failure
at org.apache.brooklyn.test.AssertsTest$4.run(AssertsTest.java:92)
at org.apache.brooklyn.test.Asserts$3.run(Asserts.java:1117)
at java.lang.Thread.run(Thread.java:745)
2017-02-15 09:39:24,776 INFO  TESTNG PASSED: "Surefire test" - 
org.apache.brooklyn.test.AssertsTest.testAssertReturnsEventuallyPropagatesException()
 finished in 4 ms
2017-02-15 09:39:24,777 INFO  TESTNG INVOKING: "Surefire test" - 
org.apache.brooklyn.test.AssertsTest.testAssertReturnsEventuallyTimesOut()
2017-02-15 09:39:24,792 INFO  TESTNG PASSED: "Surefire test" - 
org.apache.brooklyn.test.AssertsTest.testAssertReturnsEventuallyTimesOut() 
finished in 16 ms
2017-02-15 09:39:24,792 INFO  TESTNG INVOKING: "Surefire test" - 
org.apache.brooklyn.test.AssertsTest.testAssertStrings()
2017-02-15 09:39:24,793 INFO  TESTNG PASSED: "Surefire test" - 
org.apache.brooklyn.test.AssertsTest.testAssertStrings() finished in 1 ms
2017-02-15 09:39:24,793 INFO  TESTNG INVOKING: "Surefire test" - 
org.apache.brooklyn.test.AssertsTest.testExpectedFailures()
2017-02-15 09:39:24,794 WARN  Detail of unexpected error: 
java.lang.IllegalStateException
java.lang.IllegalStateException: null
at 
org.apache.brooklyn.test.AssertsTest.testExpectedFailures(AssertsTest.java:140) 
[test-classes/:na]
2017-02-15 09:39:24,794 INFO  TESTNG PASSED: "Surefire test" - 
org.apache.brooklyn.test.AssertsTest.testExpectedFailures() finished in 1 ms
2017-02-15 09:39:24,794 INFO  TESTNG INVOKING: "Surefire test" - 
org.apache.brooklyn.test.AssertsTest.testShouldHaveFailed()

[GitHub] brooklyn-client pull request #39: adds flag for connecting to servers using ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/brooklyn-client/pull/39


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