brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Zaccardo <mike.zacca...@cloudsoftcorp.com>
Subject YAML Blueprints Failing to Stop
Date Thu, 03 Dec 2015 04:52:34 GMT
Hi all,

When attempting to stop some of my more complicated YAML blueprints I have
encountered situations where certain entities will hang on the stop phase,
preventing the application from disappearing.

Below is a dummy example which demonstrates the problem.  Note that this
makes use of the `all.members.up` sensor which is not in master, so my
branch[1] must be used if you'd like to run it yourself.

BOM file: https://gist.github.com/mikezaccardo/39cc5065c10efde765d5
YAML file: https://gist.github.com/mikezaccardo/06dc8ba981694c983399

When the "Cluster Stop Test" entity is expunged, the "Core Cluster" entity
will stop correctly, but the "Secondary Cluster Entity" will hang.  This
occurs because each of the secondary cluster members will fail to resolve a
dependent value, specifically stuck on `Retrieving
$brooklyn:entity("my-core-cluster").attributeWhenReady("host.address.list.comma_separated")`
because the core cluster has already shut down.

However, if I debug and add a breakpoint to `DynamicClusterImpl` stop
method, and manually ensure that the "Secondary Cluster" stops first before
"Core Cluster", then the expunge will proceed fully without error.

The reason why I am not fully convinced that this is a Brooklyn bug is
because I reference the "my-core-cluster" ID in the BOM file, yet this is
an ID that is specified in the YAML file, which to me is a bad smell.  Is
that, in fact, bad practice from a blueprinting perspective?  If so then I
do not know how I'd properly reference that cluster by ID in the BOM.

WDYT?  I'd be glad to 1:1 with someone to think through this more.

Cheers,
Mike

[1]
https://github.com/mikezaccardo/incubator-brooklyn/tree/all-members-up-sensor

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message