[jira] [Created] (BROOKLYN-380) Add DynamicFabric.includeInitialChildren

["Aled Sage (JIRA)" <ji...@apache.org>]

Aled Sage created BROOKLYN-380:
----------------------------------

             Summary: Add DynamicFabric.includeInitialChildren
                 Key: BROOKLYN-380
                 URL: https://issues.apache.org/jira/browse/BROOKLYN-380
             Project: Brooklyn
          Issue Type: Improvement
    Affects Versions: 0.9.0
            Reporter: Aled Sage
            Priority: Minor


When writing a blueprint for a Hyperledger fabric (https://github.com/cloudsoft/brooklyn-hyperledger/), problems were hit around the way the {{DynamicRegionsFabric}} was used.

The intent is that a cluster is started in each location passed in at start-time, and that additional clusters can be added/removed later.

However, the fabric also has two additional children that are required for other purposes. Unfortunately these two children "consumed" the two startup locations (i.e. they were treated as members of the fabric group), so the two desired clusters weren't started. This behaviour of the {{DynamicFabric}} is intended and documented, so we shouldn't break that.

The workaround would be to move the two initial children to a different part of the management tree (e.g. have an app with three children: the two children mentioned above, and the fabric itself).

Longer term, we can add a config option to {{DynamicFabric}}, such as {{includeInitialChildren}} to say whether the existing children should be treated as "members", or whether new members should be created for each initial location.

See https://github.com/apache/brooklyn-server/pull/403 for an implementation of this.



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