brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aled Sage (JIRA)" <>
Subject [jira] [Resolved] (BROOKLYN-380) Add DynamicFabric.includeInitialChildren
Date Tue, 08 Nov 2016 21:02:59 GMT


Aled Sage resolved BROOKLYN-380.
       Resolution: Fixed
         Assignee: Aled Sage
    Fix Version/s: 0.10.0

> Add DynamicFabric.includeInitialChildren
> ----------------------------------------
>                 Key: BROOKLYN-380
>                 URL:
>             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 (,
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
> 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 for an implementation of this.

This message was sent by Atlassian JIRA

View raw message