How to coordinate status messaging between layers?

[Stuart Bishop]

On 3 June 2016 at 16:26, Merlijn Sebrechts <merlijn.sebrechts at gmail.com> wrote:
> Hi all
>
>
> I'm having a hard time doing status reporting from a reactive Charm. I can't
> find a good way to coordinate status messaging between different handlers
> and layers.
>
> Let me explain one of my use-cases.
>
> 1. We have a service that connects to a gateway to request a port forward.
> When the service receives such a forward, it displays this forward in its
> status message. Our management software uses this message to figure out how
> to connect to the service from the internet.
>
> 2. The service has the ability to deploy a bundle. When the bundle
> deployment fails, it goes into blocked state and shows a message explaining
> what went wrong.
>
>
> At this point, the port-forward message isn't visible anymore meaning our
> management program can't connect to the service anymore.
>
>
> Message 1 and 2 are displayed by two different layers. I can't find a good
> way to coordinate status messaging between the two layers in a way that
> keeps compatibility with all the existing layers at
> interfaces.juju.solutions.
>
> I guess what I'd like to do is have status messages that consist of multiple
> parts. Each handler can choose what part of the message to update. This
> would enable my charm to keep the port-forward information in the message
> even though another layer displays a "bundle deployment failed" message.
>
> Any idea how I can solve this? Have other people experienced similar issues?

If you need your management program to see the port-forward message
from status even after your unit has gone tits up and blocked, you
could retrieve it from the status history rather than the current
status message. I recall allowing a charm to return some extra
information to the operator separate from the workload state being
argued to death and the feature eventually killed, but maybe we do
need it.

For my work I'm using a helper to set workload status. It allows me to
pass None for the status, meaning keep the same status but change the
message. I find I can use this in most circumstances and solves a lot
of issues. Particularly dependent layers, which usually have no
business setting maintenance or active and only occasionally waiting
or blocked.

But I don't have a true solution. Its still difficult to avoid
handlers stomping over important messages when we are writing
decoupled code.

-- 
Stuart Bishop <stuart.bishop at canonical.com>