[
https://issues.apache.org/jira/browse/BROOKLYN-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aled Sage resolved BROOKLYN-380.
--------------------------------
Resolution: Fixed
Assignee: Aled Sage
Fix Version/s: 0.10.0
> 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
> Assignee: Aled Sage
> Priority: Minor
> Fix For: 0.10.0
>
>
> 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)
