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

2017-01-25 Thread Apache Jenkins Server
See 



[GitHub] brooklyn-server pull request #530: JcloudsLocation is not releasing its cust...

2017-01-25 Thread geomacy
Github user geomacy closed the pull request at:

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


---
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 #530: JcloudsLocation is not releasing its cust...

2017-01-25 Thread geomacy
GitHub user geomacy reopened a pull request:

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

JcloudsLocation is not releasing its customizers (BROOKLYN-427)

preRelease and postRelease of JcloudsLocationCustomizers are not being 
called as expected during the release of a Jclouds machine location.
The problem is that the "setup" used in JcloudsLocation.obtainOnce includes 
a copy of the flags passed from 
MachineLifecycleEffectorTasks#stopAnyProvisionedMachines,
which includes the customizers. However, the "setup" used in the "release"
method of JcloudsLocation is taken from the JcloudsLocation itself, which
is the provisioning (i.e. parent) location, which doesn't have those 
customizers in it.
It would actually make more sense to get the location customizers from
the machine location, as a given parent could have mutiple machines
with different customizers.

The changes here include an addition to the
`JcloudsCustomizerInstantiationYamlDslTest#testCustomizers`
to demonstrate the problem, and a fix that adds the config to 
the machine location.



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

$ git pull https://github.com/geomacy/brooklyn-server jclc-release

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

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


commit 6fef9147b10cdf24b2b18d9c49ee8076d60c94bd
Author: Geoff Macartney 
Date:   2017-01-19T17:10:45Z

preRelease and postRelease of JcloudsLocationCustomizers are not called on 
stop

commit 588ef4b97789770cb2fa5c48b267b35cedcc8ae3
Author: Geoff Macartney 
Date:   2017-01-19T17:28:31Z

Fix broken test for preRelease/postRelease

commit 645d59ba4ab3fa85cbf07449dbfaf4a1d0a396c9
Author: Geoff Macartney 
Date:   2017-01-25T14:55:54Z

Add the config for JCLOUDS_LOCATION_CUSTOMIZERS at construction time
so migrated settings are all at one place.




---
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-427) JcloudsLocation is not releasing its customizers

2017-01-25 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on BROOKLYN-427:
-

Github user geomacy closed the pull request at:

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


> JcloudsLocation is not releasing its customizers
> 
>
> Key: BROOKLYN-427
> URL: https://issues.apache.org/jira/browse/BROOKLYN-427
> Project: Brooklyn
>  Issue Type: Bug
>Reporter: Geoff Macartney
>Priority: Minor
>
> preRelease and postRelease of JcloudsLocationCustomizers are not being 
> called as expected during the release of a Jclouds machine location.
> The problem is that the "setup" used in JcloudsLocation.obtainOnce includes a 
> copy of the flags passed from 
> MachineLifecycleEffectorTasks#stopAnyProvisionedMachines,
> which includes the customizers. However, the "setup" used in the "release"
> method of JcloudsLocation is taken from the JcloudsLocation itself, which
> is the provisioning (i.e. parent) location, which doesn't have those 
> customizers in it. 
> It would actually make more sense to get the location customizers from
> the machine location, as a given parent could have mutiple machines
> with different customizers. 



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


[jira] [Commented] (BROOKLYN-427) JcloudsLocation is not releasing its customizers

2017-01-25 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on BROOKLYN-427:
-

Github user geomacy commented on the issue:

https://github.com/apache/brooklyn-server/pull/530
  
test failure unrelated?


> JcloudsLocation is not releasing its customizers
> 
>
> Key: BROOKLYN-427
> URL: https://issues.apache.org/jira/browse/BROOKLYN-427
> Project: Brooklyn
>  Issue Type: Bug
>Reporter: Geoff Macartney
>Priority: Minor
>
> preRelease and postRelease of JcloudsLocationCustomizers are not being 
> called as expected during the release of a Jclouds machine location.
> The problem is that the "setup" used in JcloudsLocation.obtainOnce includes a 
> copy of the flags passed from 
> MachineLifecycleEffectorTasks#stopAnyProvisionedMachines,
> which includes the customizers. However, the "setup" used in the "release"
> method of JcloudsLocation is taken from the JcloudsLocation itself, which
> is the provisioning (i.e. parent) location, which doesn't have those 
> customizers in it. 
> It would actually make more sense to get the location customizers from
> the machine location, as a given parent could have mutiple machines
> with different customizers. 



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


[jira] [Commented] (BROOKLYN-427) JcloudsLocation is not releasing its customizers

2017-01-25 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on BROOKLYN-427:
-

Github user geomacy commented on the issue:

https://github.com/apache/brooklyn-server/pull/530
  
let's try again


> JcloudsLocation is not releasing its customizers
> 
>
> Key: BROOKLYN-427
> URL: https://issues.apache.org/jira/browse/BROOKLYN-427
> Project: Brooklyn
>  Issue Type: Bug
>Reporter: Geoff Macartney
>Priority: Minor
>
> preRelease and postRelease of JcloudsLocationCustomizers are not being 
> called as expected during the release of a Jclouds machine location.
> The problem is that the "setup" used in JcloudsLocation.obtainOnce includes a 
> copy of the flags passed from 
> MachineLifecycleEffectorTasks#stopAnyProvisionedMachines,
> which includes the customizers. However, the "setup" used in the "release"
> method of JcloudsLocation is taken from the JcloudsLocation itself, which
> is the provisioning (i.e. parent) location, which doesn't have those 
> customizers in it. 
> It would actually make more sense to get the location customizers from
> the machine location, as a given parent could have mutiple machines
> with different customizers. 



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


[jira] [Commented] (BROOKLYN-427) JcloudsLocation is not releasing its customizers

2017-01-25 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on BROOKLYN-427:
-

GitHub user geomacy reopened a pull request:

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

JcloudsLocation is not releasing its customizers (BROOKLYN-427)

preRelease and postRelease of JcloudsLocationCustomizers are not being 
called as expected during the release of a Jclouds machine location.
The problem is that the "setup" used in JcloudsLocation.obtainOnce includes 
a copy of the flags passed from 
MachineLifecycleEffectorTasks#stopAnyProvisionedMachines,
which includes the customizers. However, the "setup" used in the "release"
method of JcloudsLocation is taken from the JcloudsLocation itself, which
is the provisioning (i.e. parent) location, which doesn't have those 
customizers in it.
It would actually make more sense to get the location customizers from
the machine location, as a given parent could have mutiple machines
with different customizers.

The changes here include an addition to the
`JcloudsCustomizerInstantiationYamlDslTest#testCustomizers`
to demonstrate the problem, and a fix that adds the config to 
the machine location.



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

$ git pull https://github.com/geomacy/brooklyn-server jclc-release

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

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


commit 6fef9147b10cdf24b2b18d9c49ee8076d60c94bd
Author: Geoff Macartney 
Date:   2017-01-19T17:10:45Z

preRelease and postRelease of JcloudsLocationCustomizers are not called on 
stop

commit 588ef4b97789770cb2fa5c48b267b35cedcc8ae3
Author: Geoff Macartney 
Date:   2017-01-19T17:28:31Z

Fix broken test for preRelease/postRelease

commit 645d59ba4ab3fa85cbf07449dbfaf4a1d0a396c9
Author: Geoff Macartney 
Date:   2017-01-25T14:55:54Z

Add the config for JCLOUDS_LOCATION_CUSTOMIZERS at construction time
so migrated settings are all at one place.




> JcloudsLocation is not releasing its customizers
> 
>
> Key: BROOKLYN-427
> URL: https://issues.apache.org/jira/browse/BROOKLYN-427
> Project: Brooklyn
>  Issue Type: Bug
>Reporter: Geoff Macartney
>Priority: Minor
>
> preRelease and postRelease of JcloudsLocationCustomizers are not being 
> called as expected during the release of a Jclouds machine location.
> The problem is that the "setup" used in JcloudsLocation.obtainOnce includes a 
> copy of the flags passed from 
> MachineLifecycleEffectorTasks#stopAnyProvisionedMachines,
> which includes the customizers. However, the "setup" used in the "release"
> method of JcloudsLocation is taken from the JcloudsLocation itself, which
> is the provisioning (i.e. parent) location, which doesn't have those 
> customizers in it. 
> It would actually make more sense to get the location customizers from
> the machine location, as a given parent could have mutiple machines
> with different customizers. 



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


[GitHub] brooklyn-server issue #530: JcloudsLocation is not releasing its customizers...

2017-01-25 Thread geomacy
Github user geomacy commented on the issue:

https://github.com/apache/brooklyn-server/pull/530
  
let's try 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] brooklyn-server issue #530: JcloudsLocation is not releasing its customizers...

2017-01-25 Thread geomacy
Github user geomacy commented on the issue:

https://github.com/apache/brooklyn-server/pull/530
  
test failure unrelated?


---
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-429) Brooklyn doesn't select correct public IP in OpenStack

2017-01-25 Thread Geoff Macartney (JIRA)

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

Geoff Macartney commented on BROOKLYN-429:
--

This PR may be relevant - https://github.com/apache/brooklyn-server/pull/529, 
might even fix this problem? 

> Brooklyn doesn't select correct public IP in OpenStack
> --
>
> Key: BROOKLYN-429
> URL: https://issues.apache.org/jira/browse/BROOKLYN-429
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 0.11.0
> Environment: Openstack Mitaka
>Reporter: Duncan Godwin
>Priority: Minor
>
> When launching a VM in an OpenStack instance from a Brooklyn hosted in the 
> same OpenStack private network, if 
> {{jclouds.openstack-nova.auto-create-floating-ips: true}} is selected to 
> create a floating public IP, this IP is not the one used in {{host.address}}. 
> This means that external services are unable to use values such as 
> {{main.url}} outside of the private OpenStack network.
> Presumably this is because the logic to select which IP is used for the 
> public address does not properly take into account this scenario.



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


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

2017-01-25 Thread Apache Jenkins Server
See 

--
[...truncated 22113 lines...]
Tests run: 2012, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 181.087 sec 
<<< FAILURE! - in TestSuite
(org.apache.brooklyn.core.entity.ApplicationLifecycleStateTest)  Time elapsed: 
0.074 sec  <<< FAILURE!
java.lang.AssertionError: entity=Application[mkz8tzto]; 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-01-25 17:12:01,417 INFO  Brooklyn shutdown: stopping entities 
[TestEntityImpl{id=hvk1472ky5}, TestEntityImpl{id=np66w6jj43}, 
BlockingEntityImpl{id=ef4tyxlgka}]

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[mkz8tzto]; 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: 2003, Failures: 1, Errors: 0, Skipped: 0

[JENKINS] Recording test results
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Brooklyn REST JavaScript Web GUI ... SUCCESS [01:29 min]
[INFO] Brooklyn Server Root ... SUCCESS [  5.215 s]
[INFO] Brooklyn Parent Project  SUCCESS [  5.785 s]
[INFO] Brooklyn Test Support Utilities  SUCCESS [  9.328 s]
[INFO] Brooklyn Logback Includable Configuration .. SUCCESS [  7.914 s]
[INFO] Brooklyn Common Utilities .. SUCCESS [ 32.666 s]
[INFO] Brooklyn API ... SUCCESS [  8.704 s]
[INFO] CAMP Server Parent Project . SUCCESS [  6.410 s]
[INFO] CAMP Base .. SUCCESS [ 12.151 s]
[INFO] Brooklyn Test Support .. SUCCESS [  8.223 s]
[INFO] Brooklyn REST Swagger Apidoc Utilities . SUCCESS [  8.870 s]
[INFO] Brooklyn Logback Configuration . SUCCESS [  6.384 s]
[INFO] CAMP Server  SUCCESS [ 12.724 s]
[INFO] Brooklyn Felix Runtime . SUCCESS [  9.737 s]
[INFO] Brooklyn Groovy Utilities .. SUCCESS [ 10.094 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 #529: LocationNetworkInfoCustomizer

2017-01-25 Thread neykov
Github user neykov commented on a diff in the pull request:

https://github.com/apache/brooklyn-server/pull/529#discussion_r97816042
  
--- 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 #529: LocationNetworkInfoCustomizer

2017-01-25 Thread neykov
Github user neykov commented on a diff in the pull request:

https://github.com/apache/brooklyn-server/pull/529#discussion_r97828758
  
--- 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-docs pull request #142: Added docs for useMachinePublicAddressAsPri...

2017-01-25 Thread asfgit
Github user asfgit closed the pull request at:

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


---
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-430) Azure ARM provisioning fails sometimes - no retry when rate limited

2017-01-25 Thread Aled Sage (JIRA)

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

Aled Sage commented on BROOKLYN-430:


Fixed (worked around) in https://github.com/apache/brooklyn-server/pull/535. 
Marking as resolved, but we should revisit the workaround if/when this is fixed 
in jclouds.

> Azure ARM provisioning fails sometimes - no retry when rate limited
> ---
>
> Key: BROOKLYN-430
> URL: https://issues.apache.org/jira/browse/BROOKLYN-430
> Project: Brooklyn
>  Issue Type: Bug
>Reporter: Aled Sage
> Fix For: 0.11.0
>
>
> Deploying to azure-arm (with Brooklyn 0.11.0-SNAPSHOT, using jclouds 2.0.0) 
> will often fail due to rate limiting from the azure API.
> This is reported in jclouds at 
> https://issues.apache.org/jira/browse/JCLOUDS-1229
> There is a workaround at https://github.com/apache/brooklyn-server/pull/535
> Once this is fixed in jclouds, and once we've upgraded to an official jclouds 
> release that includes the fix, then we should delete the workaround added in  
> PR #535.



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


[jira] [Resolved] (BROOKLYN-430) Azure ARM provisioning fails sometimes - no retry when rate limited

2017-01-25 Thread Aled Sage (JIRA)

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

Aled Sage resolved BROOKLYN-430.

   Resolution: Fixed
Fix Version/s: 0.11.0

> Azure ARM provisioning fails sometimes - no retry when rate limited
> ---
>
> Key: BROOKLYN-430
> URL: https://issues.apache.org/jira/browse/BROOKLYN-430
> Project: Brooklyn
>  Issue Type: Bug
>Reporter: Aled Sage
> Fix For: 0.11.0
>
>
> Deploying to azure-arm (with Brooklyn 0.11.0-SNAPSHOT, using jclouds 2.0.0) 
> will often fail due to rate limiting from the azure API.
> This is reported in jclouds at 
> https://issues.apache.org/jira/browse/JCLOUDS-1229
> There is a workaround at https://github.com/apache/brooklyn-server/pull/535
> Once this is fixed in jclouds, and once we've upgraded to an official jclouds 
> release that includes the fix, then we should delete the workaround added in  
> PR #535.



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


[GitHub] brooklyn-server pull request #535: Add jclouds AzureComputeRateLimitModule t...

2017-01-25 Thread asfgit
Github user asfgit closed the pull request at:

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


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


[GitHub] brooklyn-docs pull request #142: Added docs for useMachinePublicAddressAsPri...

2017-01-25 Thread Graeme-Miller
GitHub user Graeme-Miller opened a pull request:

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

Added docs for useMachinePublicAddressAsPrivateAddress



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

$ git pull https://github.com/Graeme-Miller/brooklyn-docs add_private_ip_doc

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

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


commit c0fcdaac46ae568ac08963afca93133d15997e5e
Author: graeme.miller 
Date:   2017-01-25T16:10:54Z

Added docs for useMachinePublicAddressAsPrivateAddress




---
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 #535: Add jclouds AzureComputeRateLimitModule to suppo...

2017-01-25 Thread tbouron
Github user tbouron commented on the issue:

https://github.com/apache/brooklyn-server/pull/535
  
@aledsage done



---
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] [Created] (BROOKLYN-431) br cli doesn't return error when unauthroized

2017-01-25 Thread Valentin Aitken (JIRA)
Valentin Aitken created BROOKLYN-431:


 Summary: br cli doesn't return error when unauthroized
 Key: BROOKLYN-431
 URL: https://issues.apache.org/jira/browse/BROOKLYN-431
 Project: Brooklyn
  Issue Type: Bug
Reporter: Valentin Aitken
Priority: Minor
 Fix For: 0.11.0


Using wrong credentials is not reported.

{noformat}
$ br login http://localhost:8081 adminuser wrongpassword

$ br catalog add ./some.bom

$ br entity x
Error: 401 Unauthorized
{noformat}
It is reported for {{br entity}} however



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


[GitHub] brooklyn-server issue #535: Add jclouds AzureComputeRateLimitModule to suppo...

2017-01-25 Thread aledsage
Github user aledsage commented on the issue:

https://github.com/apache/brooklyn-server/pull/535
  
The test failure is unrelated, and should be investigated/fixed separately:

```
java.lang.AssertionError: entity=Application[802qtu86]; 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)
```

@tbouron can you trigger jenkins to build again please, e.g. by doing `git 
commit --amend; git push -f`


---
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-430) Azure ARM provisioning fails sometimes - no retry when rate limited

2017-01-25 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on BROOKLYN-430:
-

Github user aledsage commented on the issue:

https://github.com/apache/brooklyn-server/pull/535
  
Thanks @tbouron - LGTM. Once jenkins has finished running the tests, I'll 
merge this.

I've created https://issues.apache.org/jira/browse/BROOKLYN-430 to track 
this in brooklyn, which just links to jclouds 
https://issues.apache.org/jira/browse/JCLOUDS-1229.


> Azure ARM provisioning fails sometimes - no retry when rate limited
> ---
>
> Key: BROOKLYN-430
> URL: https://issues.apache.org/jira/browse/BROOKLYN-430
> Project: Brooklyn
>  Issue Type: Bug
>Reporter: Aled Sage
>
> Deploying to azure-arm (with Brooklyn 0.11.0-SNAPSHOT, using jclouds 2.0.0) 
> will often fail due to rate limiting from the azure API.
> This is reported in jclouds at 
> https://issues.apache.org/jira/browse/JCLOUDS-1229
> There is a workaround at https://github.com/apache/brooklyn-server/pull/535
> Once this is fixed in jclouds, and once we've upgraded to an official jclouds 
> release that includes the fix, then we should delete the workaround added in  
> PR #535.



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


[GitHub] brooklyn-server issue #535: Add jclouds AzureComputeRateLimitModule to suppo...

2017-01-25 Thread aledsage
Github user aledsage commented on the issue:

https://github.com/apache/brooklyn-server/pull/535
  
Thanks @tbouron - LGTM. Once jenkins has finished running the tests, I'll 
merge this.

I've created https://issues.apache.org/jira/browse/BROOKLYN-430 to track 
this in brooklyn, which just links to jclouds 
https://issues.apache.org/jira/browse/JCLOUDS-1229.


---
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] [Created] (BROOKLYN-430) Azure ARM provisioning fails sometimes - no retry when rate limited

2017-01-25 Thread Aled Sage (JIRA)
Aled Sage created BROOKLYN-430:
--

 Summary: Azure ARM provisioning fails sometimes - no retry when 
rate limited
 Key: BROOKLYN-430
 URL: https://issues.apache.org/jira/browse/BROOKLYN-430
 Project: Brooklyn
  Issue Type: Bug
Reporter: Aled Sage


Deploying to azure-arm (with Brooklyn 0.11.0-SNAPSHOT, using jclouds 2.0.0) 
will often fail due to rate limiting from the azure API.

This is reported in jclouds at 
https://issues.apache.org/jira/browse/JCLOUDS-1229

There is a workaround at https://github.com/apache/brooklyn-server/pull/535

Once this is fixed in jclouds, and once we've upgraded to an official jclouds 
release that includes the fix, then we should delete the workaround added in  
PR #535.



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


[GitHub] brooklyn-server pull request #535: Add jclouds AzureComputeRateLimitModule t...

2017-01-25 Thread tbouron
GitHub user tbouron opened a pull request:

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

Add jclouds AzureComputeRateLimitModule to support provisioning retry for 
Azure ARM



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

$ git pull https://github.com/tbouron/brooklyn-server fix/azure-arm-retry

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

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


commit 1bfb8eb9e569e94388dd617d07ac705e0b30b0b1
Author: Thomas Bouron 
Date:   2017-01-25T15:30:44Z

Add jclouds AzureComputeRateLimitModule to support provisioning retry for 
Azure ARM




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


[jira] [Updated] (BROOKLYN-429) Brooklyn doesn't select correct public IP in OpenStack

2017-01-25 Thread Duncan Godwin (JIRA)

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

Duncan Godwin updated BROOKLYN-429:
---
Description: 
When launching a VM in an OpenStack instance from a Brooklyn hosted in the same 
OpenStack private network, if 
{{jclouds.openstack-nova.auto-create-floating-ips: true}} is selected to create 
a floating public IP, this IP is not the one used in {{host.address}}. This 
means that external services are unable to use values such as {{main.url}} 
outside of the private OpenStack network.

Presumably this is because the logic to select which IP is used for the public 
address does not properly take into account this scenario.

  was:
When launching a VM in an OpenStack instance from a Brooklyn hosted in the same 
OpenStack private network, if `jclouds.openstack-nova.auto-create-floating-ips: 
true` is selected to create a floating public IP, this IP is not the one used 
in `host.address`. This means that external services are unable to use values 
such as `main.url` outside of the private OpenStack network.

Presumably this is because the logic to select which IP is used for the public 
address does not properly take into account this scenario.


> Brooklyn doesn't select correct public IP in OpenStack
> --
>
> Key: BROOKLYN-429
> URL: https://issues.apache.org/jira/browse/BROOKLYN-429
> Project: Brooklyn
>  Issue Type: Bug
>Affects Versions: 0.11.0
> Environment: Openstack Mitaka
>Reporter: Duncan Godwin
>Priority: Minor
>
> When launching a VM in an OpenStack instance from a Brooklyn hosted in the 
> same OpenStack private network, if 
> {{jclouds.openstack-nova.auto-create-floating-ips: true}} is selected to 
> create a floating public IP, this IP is not the one used in {{host.address}}. 
> This means that external services are unable to use values such as 
> {{main.url}} outside of the private OpenStack network.
> Presumably this is because the logic to select which IP is used for the 
> public address does not properly take into account this scenario.



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


[jira] [Created] (BROOKLYN-429) Brooklyn doesn't select correct public IP in OpenStack

2017-01-25 Thread Duncan Godwin (JIRA)
Duncan Godwin created BROOKLYN-429:
--

 Summary: Brooklyn doesn't select correct public IP in OpenStack
 Key: BROOKLYN-429
 URL: https://issues.apache.org/jira/browse/BROOKLYN-429
 Project: Brooklyn
  Issue Type: Bug
Affects Versions: 0.11.0
 Environment: Openstack Mitaka
Reporter: Duncan Godwin
Priority: Minor


When launching a VM in an OpenStack instance from a Brooklyn hosted in the same 
OpenStack private network, if `jclouds.openstack-nova.auto-create-floating-ips: 
true` is selected to create a floating public IP, this IP is not the one used 
in `host.address`. This means that external services are unable to use values 
such as `main.url` outside of the private OpenStack network.

Presumably this is because the logic to select which IP is used for the public 
address does not properly take into account this scenario.



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


[GitHub] brooklyn-server issue #520: Limit parallelism of start/stop steps on Softwar...

2017-01-25 Thread neykov
Github user neykov commented on the issue:

https://github.com/apache/brooklyn-server/pull/520
  
@geomacy, @sam addressed comments.


---
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 #520: Limit parallelism of start/stop steps on ...

2017-01-25 Thread neykov
Github user neykov commented on a diff in the pull request:

https://github.com/apache/brooklyn-server/pull/520#discussion_r97798251
  
--- Diff: 
core/src/main/java/org/apache/brooklyn/core/sensor/ReleaseableLatch.java ---
@@ -0,0 +1,95 @@
+/*
+ * 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.core.sensor;
+
+import java.util.concurrent.Semaphore;
+
+import org.apache.brooklyn.api.entity.Entity;
+import org.apache.brooklyn.util.core.task.DeferredSupplier;
+import org.apache.brooklyn.util.core.task.ImmediateSupplier;
+import org.apache.brooklyn.util.exceptions.Exceptions;
+import org.apache.brooklyn.util.guava.Maybe;
+
+// DeferredSupplier used as a marker interface to prevent coercion. When 
resolved it must evaluate to {@code Boolean.TRUE}.
+public interface ReleaseableLatch extends DeferredSupplier, 
ImmediateSupplier {
+/**
+ * Increment usage count for the {@code caller} entity
+ */
+void acquire(Entity caller);
+
+/**
+ * Decrement usage count for the {@code caller} entity
+ */
+void release(Entity caller);
+
+static abstract class AbstractReleaseableLatch implements 
ReleaseableLatch {
+// Instances coerce to TRUE as they are non-null.
+@Override public Boolean get() {return Boolean.TRUE;}
+@Override public Maybe getImmediately() {return 
Maybe.of(Boolean.TRUE);}
+}
+
+ReleaseableLatch NOP = new Factory.NopLatch();
+
+static class Factory {
+private static class NopLatch extends AbstractReleaseableLatch {
+@Override public void acquire(Entity caller) {}
+@Override public void release(Entity caller) {}
+}
+
+private static class MaxConcurrencyLatch extends 
AbstractReleaseableLatch {
+private int permits;
+private transient final Semaphore sem;
+
+public MaxConcurrencyLatch(int permits) {
+this.permits = permits;
+this.sem = new Semaphore(permits);
+}
+
+@Override
+public void acquire(Entity caller) {
--- End diff --

Updated doc. I'd expect the entity would match on acquire/release - added 
info for the argument as well.


---
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-427) JcloudsLocation is not releasing its customizers

2017-01-25 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on BROOKLYN-427:
-

Github user geomacy commented on the issue:

https://github.com/apache/brooklyn-server/pull/530
  
Addressed review 
[comment](https://github.com/apache/brooklyn-server/pull/530#discussion_r97329773)
 "Can you instead add the config for JCLOUDS_LOCATION_CUSTOMIZERS..."


> JcloudsLocation is not releasing its customizers
> 
>
> Key: BROOKLYN-427
> URL: https://issues.apache.org/jira/browse/BROOKLYN-427
> Project: Brooklyn
>  Issue Type: Bug
>Reporter: Geoff Macartney
>Priority: Minor
>
> preRelease and postRelease of JcloudsLocationCustomizers are not being 
> called as expected during the release of a Jclouds machine location.
> The problem is that the "setup" used in JcloudsLocation.obtainOnce includes a 
> copy of the flags passed from 
> MachineLifecycleEffectorTasks#stopAnyProvisionedMachines,
> which includes the customizers. However, the "setup" used in the "release"
> method of JcloudsLocation is taken from the JcloudsLocation itself, which
> is the provisioning (i.e. parent) location, which doesn't have those 
> customizers in it. 
> It would actually make more sense to get the location customizers from
> the machine location, as a given parent could have mutiple machines
> with different customizers. 



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


[GitHub] brooklyn-server issue #530: JcloudsLocation is not releasing its customizers...

2017-01-25 Thread geomacy
Github user geomacy commented on the issue:

https://github.com/apache/brooklyn-server/pull/530
  
Addressed review 
[comment](https://github.com/apache/brooklyn-server/pull/530#discussion_r97329773)
 "Can you instead add the config for JCLOUDS_LOCATION_CUSTOMIZERS..."


---
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 #520: Limit parallelism of start/stop steps on ...

2017-01-25 Thread geomacy
Github user geomacy commented on a diff in the pull request:

https://github.com/apache/brooklyn-server/pull/520#discussion_r97794412
  
--- Diff: 
software/base/src/main/java/org/apache/brooklyn/entity/software/base/lifecycle/MachineLifecycleEffectorTasks.java
 ---
@@ -1083,4 +1146,39 @@ protected void 
clearEntityLocationAttributes(Location machine) {
 entity().sensors().set(Attributes.SUBNET_ADDRESS, null);
 }
 
+public static ReleaseableLatch waitForLatch(EntityInternal entity, 
ConfigKey configKey) {
+Maybe rawValue = entity.config().getRaw(configKey);
+if (rawValue.isAbsent()) {
+return ReleaseableLatch.NOP;
+} else {
+ValueResolverIterator iter = 
resolveLatchIterator(entity, rawValue.get(), configKey);
+Maybe releasableLatchMaybe = 
iter.next(ReleaseableLatch.class);
--- End diff --

ah cool


---
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 #520: Limit parallelism of start/stop steps on ...

2017-01-25 Thread geomacy
Github user geomacy commented on a diff in the pull request:

https://github.com/apache/brooklyn-server/pull/520#discussion_r97794132
  
--- Diff: 
core/src/main/java/org/apache/brooklyn/core/sensor/ReleaseableLatch.java ---
@@ -0,0 +1,95 @@
+/*
+ * 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.core.sensor;
+
+import java.util.concurrent.Semaphore;
+
+import org.apache.brooklyn.api.entity.Entity;
+import org.apache.brooklyn.util.core.task.DeferredSupplier;
+import org.apache.brooklyn.util.core.task.ImmediateSupplier;
+import org.apache.brooklyn.util.exceptions.Exceptions;
+import org.apache.brooklyn.util.guava.Maybe;
+
+// DeferredSupplier used as a marker interface to prevent coercion. When 
resolved it must evaluate to {@code Boolean.TRUE}.
+public interface ReleaseableLatch extends DeferredSupplier, 
ImmediateSupplier {
+/**
+ * Increment usage count for the {@code caller} entity
+ */
+void acquire(Entity caller);
+
+/**
+ * Decrement usage count for the {@code caller} entity
+ */
+void release(Entity caller);
+
+static abstract class AbstractReleaseableLatch implements 
ReleaseableLatch {
+// Instances coerce to TRUE as they are non-null.
+@Override public Boolean get() {return Boolean.TRUE;}
+@Override public Maybe getImmediately() {return 
Maybe.of(Boolean.TRUE);}
+}
+
+ReleaseableLatch NOP = new Factory.NopLatch();
+
+static class Factory {
+private static class NopLatch extends AbstractReleaseableLatch {
+@Override public void acquire(Entity caller) {}
+@Override public void release(Entity caller) {}
+}
+
+private static class MaxConcurrencyLatch extends 
AbstractReleaseableLatch {
+private int permits;
+private transient final Semaphore sem;
+
+public MaxConcurrencyLatch(int permits) {
+this.permits = permits;
+this.sem = new Semaphore(permits);
+}
+
+@Override
+public void acquire(Entity caller) {
--- End diff --

makes sense; I think it probably would be worth adding the comment that the 
entity MAY be ignored by implementations, and callers shouldn't assume any 
specific behaviour based on entity, i.e. don't assume you have to match 
`acquire()`/`release()` on the same entity.


---
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 #520: Limit parallelism of start/stop steps on ...

2017-01-25 Thread neykov
Github user neykov commented on a diff in the pull request:

https://github.com/apache/brooklyn-server/pull/520#discussion_r97789383
  
--- Diff: 
software/base/src/main/java/org/apache/brooklyn/entity/software/base/lifecycle/MachineLifecycleEffectorTasks.java
 ---
@@ -944,14 +1002,19 @@ protected static boolean canStop(StopMode stopMode, 
boolean isStopped) {
 stopMode == StopMode.IF_NOT_STOPPED && !isStopped;
 }
 
+/** @deprecated since 0.11.0. Use {@link 
#preStopConfirmCustom(AtomicReference)} instead. */
+@Deprecated
+protected void preStopConfirmCustom() {
+preStopConfirmCustom(RELEASEABLE_LATCH_TL.get());
+}
+
 /** 
  * Override to check whether stop can be executed.
  * Throw if stop should be aborted.
  */
-protected void preStopConfirmCustom() {
+protected void preStopConfirmCustom(AtomicReference 
stopLatchRef) {
 // Opportunity to block stop() until other dependent components 
are ready for it
-Object val = entity().getConfig(SoftwareProcess.STOP_LATCH);
-if (val != null) log.debug("{} finished waiting for stop-latch {}; 
continuing...", entity(), val);
+stopLatchRef.set(waitForLatch(entity(), 
SoftwareProcess.STOP_LATCH));
--- End diff --

Good cleanup, will update.


---
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 #520: Limit parallelism of start/stop steps on ...

2017-01-25 Thread neykov
Github user neykov commented on a diff in the pull request:

https://github.com/apache/brooklyn-server/pull/520#discussion_r97790853
  
--- Diff: 
core/src/main/java/org/apache/brooklyn/core/sensor/ReleaseableLatch.java ---
@@ -0,0 +1,95 @@
+/*
+ * 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.core.sensor;
+
+import java.util.concurrent.Semaphore;
+
+import org.apache.brooklyn.api.entity.Entity;
+import org.apache.brooklyn.util.core.task.DeferredSupplier;
+import org.apache.brooklyn.util.core.task.ImmediateSupplier;
+import org.apache.brooklyn.util.exceptions.Exceptions;
+import org.apache.brooklyn.util.guava.Maybe;
+
+// DeferredSupplier used as a marker interface to prevent coercion. When 
resolved it must evaluate to {@code Boolean.TRUE}.
+public interface ReleaseableLatch extends DeferredSupplier, 
ImmediateSupplier {
+/**
+ * Increment usage count for the {@code caller} entity
+ */
+void acquire(Entity caller);
+
+/**
+ * Decrement usage count for the {@code caller} entity
+ */
+void release(Entity caller);
+
+static abstract class AbstractReleaseableLatch implements 
ReleaseableLatch {
+// Instances coerce to TRUE as they are non-null.
+@Override public Boolean get() {return Boolean.TRUE;}
+@Override public Maybe getImmediately() {return 
Maybe.of(Boolean.TRUE);}
+}
+
+ReleaseableLatch NOP = new Factory.NopLatch();
+
+static class Factory {
+private static class NopLatch extends AbstractReleaseableLatch {
+@Override public void acquire(Entity caller) {}
+@Override public void release(Entity caller) {}
+}
+
+private static class MaxConcurrencyLatch extends 
AbstractReleaseableLatch {
--- End diff --

Two reasons:
  * Personal preference to inline small classes like this.
  * More importantly to hide the implementation and make it private.


---
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 #520: Limit parallelism of start/stop steps on ...

2017-01-25 Thread neykov
Github user neykov commented on a diff in the pull request:

https://github.com/apache/brooklyn-server/pull/520#discussion_r97790274
  
--- Diff: 
software/base/src/main/java/org/apache/brooklyn/entity/software/base/lifecycle/MachineLifecycleEffectorTasks.java
 ---
@@ -1083,4 +1146,39 @@ protected void 
clearEntityLocationAttributes(Location machine) {
 entity().sensors().set(Attributes.SUBNET_ADDRESS, null);
 }
 
+public static ReleaseableLatch waitForLatch(EntityInternal entity, 
ConfigKey configKey) {
+Maybe rawValue = entity.config().getRaw(configKey);
+if (rawValue.isAbsent()) {
+return ReleaseableLatch.NOP;
+} else {
+ValueResolverIterator iter = 
resolveLatchIterator(entity, rawValue.get(), configKey);
+Maybe releasableLatchMaybe = 
iter.next(ReleaseableLatch.class);
--- End diff --

`next(Class type)` will return the first element instance of `type` - 
it's doing the looping under the hood.


---
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 #520: Limit parallelism of start/stop steps on ...

2017-01-25 Thread neykov
Github user neykov commented on a diff in the pull request:

https://github.com/apache/brooklyn-server/pull/520#discussion_r97789809
  
--- Diff: 
core/src/main/java/org/apache/brooklyn/core/sensor/ReleaseableLatch.java ---
@@ -0,0 +1,95 @@
+/*
+ * 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.core.sensor;
+
+import java.util.concurrent.Semaphore;
+
+import org.apache.brooklyn.api.entity.Entity;
+import org.apache.brooklyn.util.core.task.DeferredSupplier;
+import org.apache.brooklyn.util.core.task.ImmediateSupplier;
+import org.apache.brooklyn.util.exceptions.Exceptions;
+import org.apache.brooklyn.util.guava.Maybe;
+
+// DeferredSupplier used as a marker interface to prevent coercion. When 
resolved it must evaluate to {@code Boolean.TRUE}.
+public interface ReleaseableLatch extends DeferredSupplier, 
ImmediateSupplier {
+/**
+ * Increment usage count for the {@code caller} entity
+ */
+void acquire(Entity caller);
+
+/**
+ * Decrement usage count for the {@code caller} entity
+ */
+void release(Entity caller);
+
+static abstract class AbstractReleaseableLatch implements 
ReleaseableLatch {
+// Instances coerce to TRUE as they are non-null.
+@Override public Boolean get() {return Boolean.TRUE;}
+@Override public Maybe getImmediately() {return 
Maybe.of(Boolean.TRUE);}
+}
+
+ReleaseableLatch NOP = new Factory.NopLatch();
+
+static class Factory {
+private static class NopLatch extends AbstractReleaseableLatch {
+@Override public void acquire(Entity caller) {}
+@Override public void release(Entity caller) {}
+}
+
+private static class MaxConcurrencyLatch extends 
AbstractReleaseableLatch {
+private int permits;
+private transient final Semaphore sem;
+
+public MaxConcurrencyLatch(int permits) {
+this.permits = permits;
+this.sem = new Semaphore(permits);
+}
+
+@Override
+public void acquire(Entity caller) {
--- End diff --

I've designed the API such that it doesn't assume a semaphore below. Could 
be used in different ways - for example to replicate the 
`maxConcurrentChildCommands` behaviour. So while it's not used in this 
particular implementation, could be useful for alternative implementations.


---
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 #520: Limit parallelism of start/stop steps on ...

2017-01-25 Thread neykov
Github user neykov commented on a diff in the pull request:

https://github.com/apache/brooklyn-server/pull/520#discussion_r97789510
  
--- Diff: 
software/base/src/main/java/org/apache/brooklyn/entity/software/base/lifecycle/MachineLifecycleEffectorTasks.java
 ---
@@ -731,15 +774,30 @@ protected void restartChildren(ConfigBag parameters) {
  * If no errors were encountered call {@link #postStopCustom()} at the 
end.
  */
 public void stop(ConfigBag parameters) {
-doStop(parameters, new StopAnyProvisionedMachinesTask());
+doStopLatching(parameters, new StopAnyProvisionedMachinesTask());
 }
 
 /**
  * As {@link #stop} but calling {@link #suspendAnyProvisionedMachines} 
rather than
  * {@link #stopAnyProvisionedMachines}.
  */
 public void suspend(ConfigBag parameters) {
-doStop(parameters, new SuspendAnyProvisionedMachinesTask());
+doStopLatching(parameters, new 
SuspendAnyProvisionedMachinesTask());
+}
+
+protected void doStopLatching(ConfigBag parameters, 
Callable stopTask) {
--- End diff --

It does now after latest changes :)


---
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 #520: Limit parallelism of start/stop steps on ...

2017-01-25 Thread geomacy
Github user geomacy commented on a diff in the pull request:

https://github.com/apache/brooklyn-server/pull/520#discussion_r97757004
  
--- Diff: 
software/base/src/main/java/org/apache/brooklyn/entity/software/base/lifecycle/MachineLifecycleEffectorTasks.java
 ---
@@ -731,15 +774,30 @@ protected void restartChildren(ConfigBag parameters) {
  * If no errors were encountered call {@link #postStopCustom()} at the 
end.
  */
 public void stop(ConfigBag parameters) {
-doStop(parameters, new StopAnyProvisionedMachinesTask());
+doStopLatching(parameters, new StopAnyProvisionedMachinesTask());
 }
 
 /**
  * As {@link #stop} but calling {@link #suspendAnyProvisionedMachines} 
rather than
  * {@link #stopAnyProvisionedMachines}.
  */
 public void suspend(ConfigBag parameters) {
-doStop(parameters, new SuspendAnyProvisionedMachinesTask());
+doStopLatching(parameters, new 
SuspendAnyProvisionedMachinesTask());
+}
+
+protected void doStopLatching(ConfigBag parameters, 
Callable stopTask) {
--- End diff --

Despite the name, this doesn't actually aquire the latch - that's left to 
the `doStop` - see comment on `preStopConfirm` below.


---
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 #520: Limit parallelism of start/stop steps on ...

2017-01-25 Thread geomacy
Github user geomacy commented on a diff in the pull request:

https://github.com/apache/brooklyn-server/pull/520#discussion_r97598531
  
--- Diff: 
core/src/main/java/org/apache/brooklyn/core/sensor/ReleaseableLatch.java ---
@@ -0,0 +1,95 @@
+/*
+ * 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.core.sensor;
+
+import java.util.concurrent.Semaphore;
+
+import org.apache.brooklyn.api.entity.Entity;
+import org.apache.brooklyn.util.core.task.DeferredSupplier;
+import org.apache.brooklyn.util.core.task.ImmediateSupplier;
+import org.apache.brooklyn.util.exceptions.Exceptions;
+import org.apache.brooklyn.util.guava.Maybe;
+
+// DeferredSupplier used as a marker interface to prevent coercion. When 
resolved it must evaluate to {@code Boolean.TRUE}.
+public interface ReleaseableLatch extends DeferredSupplier, 
ImmediateSupplier {
+/**
+ * Increment usage count for the {@code caller} entity
+ */
+void acquire(Entity caller);
+
+/**
+ * Decrement usage count for the {@code caller} entity
+ */
+void release(Entity caller);
+
+static abstract class AbstractReleaseableLatch implements 
ReleaseableLatch {
+// Instances coerce to TRUE as they are non-null.
+@Override public Boolean get() {return Boolean.TRUE;}
+@Override public Maybe getImmediately() {return 
Maybe.of(Boolean.TRUE);}
+}
+
+ReleaseableLatch NOP = new Factory.NopLatch();
+
+static class Factory {
+private static class NopLatch extends AbstractReleaseableLatch {
+@Override public void acquire(Entity caller) {}
+@Override public void release(Entity caller) {}
+}
+
+private static class MaxConcurrencyLatch extends 
AbstractReleaseableLatch {
--- End diff --

why put this inside here? Is it not better to put this more specific 
implementation in its own file? 


---
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 #520: Limit parallelism of start/stop steps on ...

2017-01-25 Thread geomacy
Github user geomacy commented on a diff in the pull request:

https://github.com/apache/brooklyn-server/pull/520#discussion_r97600990
  
--- Diff: 
core/src/main/java/org/apache/brooklyn/core/sensor/ReleaseableLatch.java ---
@@ -0,0 +1,95 @@
+/*
+ * 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.core.sensor;
+
+import java.util.concurrent.Semaphore;
+
+import org.apache.brooklyn.api.entity.Entity;
+import org.apache.brooklyn.util.core.task.DeferredSupplier;
+import org.apache.brooklyn.util.core.task.ImmediateSupplier;
+import org.apache.brooklyn.util.exceptions.Exceptions;
+import org.apache.brooklyn.util.guava.Maybe;
+
+// DeferredSupplier used as a marker interface to prevent coercion. When 
resolved it must evaluate to {@code Boolean.TRUE}.
+public interface ReleaseableLatch extends DeferredSupplier, 
ImmediateSupplier {
+/**
+ * Increment usage count for the {@code caller} entity
+ */
+void acquire(Entity caller);
+
+/**
+ * Decrement usage count for the {@code caller} entity
+ */
+void release(Entity caller);
+
+static abstract class AbstractReleaseableLatch implements 
ReleaseableLatch {
+// Instances coerce to TRUE as they are non-null.
+@Override public Boolean get() {return Boolean.TRUE;}
+@Override public Maybe getImmediately() {return 
Maybe.of(Boolean.TRUE);}
+}
+
+ReleaseableLatch NOP = new Factory.NopLatch();
+
+static class Factory {
+private static class NopLatch extends AbstractReleaseableLatch {
+@Override public void acquire(Entity caller) {}
+@Override public void release(Entity caller) {}
+}
+
+private static class MaxConcurrencyLatch extends 
AbstractReleaseableLatch {
+private int permits;
+private transient final Semaphore sem;
+
+public MaxConcurrencyLatch(int permits) {
+this.permits = permits;
+this.sem = new Semaphore(permits);
+}
+
+@Override
+public void acquire(Entity caller) {
--- End diff --

Why is no use made of `caller` here and in `release` - by the description 
of the contract above "Increment usage count for the {@code caller} entity" 
surely it should?   Reading that, I wouldn't expect that if I have two entities 
and do `latch.acquire(entity1)`, I would then be able to do 
`latch.release(entity2)`, or indeed `latch.release(null)`, and still release a 
permit on the semaphore, but that's what will happen.  It may be worth updating 
the comment to indicate that implementations are free to ignore the entity if 
that suits them.


---
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 #520: Limit parallelism of start/stop steps on ...

2017-01-25 Thread geomacy
Github user geomacy commented on a diff in the pull request:

https://github.com/apache/brooklyn-server/pull/520#discussion_r97746296
  
--- Diff: 
software/base/src/main/java/org/apache/brooklyn/entity/software/base/lifecycle/MachineLifecycleEffectorTasks.java
 ---
@@ -1083,4 +1146,39 @@ protected void 
clearEntityLocationAttributes(Location machine) {
 entity().sensors().set(Attributes.SUBNET_ADDRESS, null);
 }
 
+public static ReleaseableLatch waitForLatch(EntityInternal entity, 
ConfigKey configKey) {
+Maybe rawValue = entity.config().getRaw(configKey);
+if (rawValue.isAbsent()) {
+return ReleaseableLatch.NOP;
+} else {
+ValueResolverIterator iter = 
resolveLatchIterator(entity, rawValue.get(), configKey);
+Maybe releasableLatchMaybe = 
iter.next(ReleaseableLatch.class);
--- End diff --

Should this be a `for` loop? Given that you have your new iterator here, is 
is not possible for the latch to be several iterations down inside some nested 
expression?


---
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 #520: Limit parallelism of start/stop steps on ...

2017-01-25 Thread geomacy
Github user geomacy commented on a diff in the pull request:

https://github.com/apache/brooklyn-server/pull/520#discussion_r97756033
  
--- Diff: 
software/base/src/main/java/org/apache/brooklyn/entity/software/base/lifecycle/MachineLifecycleEffectorTasks.java
 ---
@@ -944,14 +1002,19 @@ protected static boolean canStop(StopMode stopMode, 
boolean isStopped) {
 stopMode == StopMode.IF_NOT_STOPPED && !isStopped;
 }
 
+/** @deprecated since 0.11.0. Use {@link 
#preStopConfirmCustom(AtomicReference)} instead. */
+@Deprecated
+protected void preStopConfirmCustom() {
+preStopConfirmCustom(RELEASEABLE_LATCH_TL.get());
+}
+
 /** 
  * Override to check whether stop can be executed.
  * Throw if stop should be aborted.
  */
-protected void preStopConfirmCustom() {
+protected void preStopConfirmCustom(AtomicReference 
stopLatchRef) {
 // Opportunity to block stop() until other dependent components 
are ready for it
-Object val = entity().getConfig(SoftwareProcess.STOP_LATCH);
-if (val != null) log.debug("{} finished waiting for stop-latch {}; 
continuing...", entity(), val);
+stopLatchRef.set(waitForLatch(entity(), 
SoftwareProcess.STOP_LATCH));
--- End diff --

Is it advisable to do this outside the protected method, to avoid 
possibility of subclasses forgetting to call super(). - i.e. wrap 
the`protected` method in something `private` that sets the latch reference then 
calls the protected method.  Perhaps this line should go into `doStopLatching` 
just before the call to `doStop()`.  Same for the other latches, START etc.


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