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)
