How to coordinate status messaging between layers?

[John Meinel]

Using the workload message as a single location to convey information to
the outside world was certainly never intended. Generally those messages
were meant to convey information to a human who would be looking at them.

We've actually had quite a few conversations about opening up more avenues
for charms to convey information to the outside world (and possibly to each
other). It was something that got pushed out of this cycle, but I certainly
believe it is still in the "things to be done" rather than the "things we
won't do" pile.

John
=:->


On Fri, Jun 3, 2016 at 3:26 PM, Stuart Bishop <stuart.bishop at canonical.com>
wrote:

> 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>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160606/ff3a5d6f/attachment.html>