Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.apache.org
From: Svetoslav Neykov <svetoslav.neykov@cloudsoftcorp.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: UsageListener: notified of promotion to master?
Date: Wed, 22 Mar 2017 21:52:00 +0200
References: <aeb7141c-6f16-8a83-284b-240b4678a8f5@gmail.com>
To: dev@brooklyn.apache.org
In-Reply-To: <aeb7141c-6f16-8a83-284b-240b4678a8f5@gmail.com>
Message-Id: <B4504909-62D3-497B-9A40-5893C14BAF20@cloudsoftcorp.com>
archived-at: Wed, 22 Mar 2017 20:17:33 -0000

> It feels like (2) is a more generally useful feature to add (for =
programmatic support, at least). Does it sound useful for things beyond =
my use-case?

Yes. I needed this exact functionality last week - for a piece of code =
shared between all applications. I ended up writing a poller thread that =
monitors the state.=20
I think it will be a useful thing to add.

Svet.


> On 22.03.2017 =D0=B3., at 19:11, Aled Sage <aled.sage@gmail.com> =
wrote:
>=20
> Hi all,
>=20
> I'm writing a UsageListener [1] that is going to record the Brooklyn =
instance's apps in an external inventory. This is mostly =
straight-forward (except needing the fix at [2]).
>=20
> The tricky bit is when a Brooklyn standby instance is promoted to =
master - I want my listener to be notified so it can record the identity =
of the new master Brooklyn for each of the pre-existing app.
>=20
> I don't see anywhere I can get a notification of this. Is there?
>=20
> ---
>=20
> Possible solutions include:
>=20
> 1. Add an additional application event (e.g. state
>   "MANAGEMENT_CHANGED") - the UsageListener would receive this event
>   for every app when it successfully rebinds.
> 2. Register a new kind of listener, to be notified of the management
>   context's state - on becoming "master", my listener could iterate
>   over all the apps.
>=20
> I don't particularly like either of those options.
>=20
> For (1), it isn't really to do with app "Usage" like the other events.
>=20
> For (2), my listener code would be fiddly - I'd need to worry about =
receiving concurrent notifications via the normal UsageListener while =
I'm iterating over the pre-existing apps (assuming the new listener is =
called asynchronously, rather than blocking the management context's =
startup).
>=20
> It feels like (2) is a more generally useful feature to add (for =
programmatic support, at least). Does it sound useful for things beyond =
my use-case?
>=20
> Thoughts?
>=20
> Aled
>=20
> [1] =
https://github.com/apache/brooklyn-server/blob/master/core/src/main/java/o=
rg/apache/brooklyn/core/mgmt/usage/UsageListener.java
> [2] https://github.com/apache/brooklyn-server/pull/606
>=20
>=20