You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Aled Sage <al...@gmail.com> on 2017/09/19 20:09:49 UTC

Re: UsageListener: notified of promotion to master?

Hi all,

I finally got round to implementing this! See PR at 
https://github.com/apache/brooklyn-server/pull/832

Aled


On 22/03/2017 19:52, Svetoslav Neykov wrote:
>> 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.
> I think it will be a useful thing to add.
>
> Svet.
>
>
>> On 22.03.2017 г., at 19:11, Aled Sage <al...@gmail.com> wrote:
>>
>> Hi all,
>>
>> 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]).
>>
>> 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.
>>
>> I don't see anywhere I can get a notification of this. Is there?
>>
>> ---
>>
>> Possible solutions include:
>>
>> 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.
>>
>> I don't particularly like either of those options.
>>
>> For (1), it isn't really to do with app "Usage" like the other events.
>>
>> 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).
>>
>> 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?
>>
>> Thoughts?
>>
>> Aled
>>
>> [1] https://github.com/apache/brooklyn-server/blob/master/core/src/main/java/org/apache/brooklyn/core/mgmt/usage/UsageListener.java
>> [2] https://github.com/apache/brooklyn-server/pull/606
>>
>>