Uniter tests for update-status hook - BLOCKER

[William Reade]

On Mon, Jul 20, 2015 at 4:57 PM, roger peppe <rogpeppe at gmail.com> wrote:
>
> That's somewhat harder with the uniter, because its very state-dependent
> channel operations make it awkward to write a uniform outer select loop.
>
> If I were to do it, off the top of my head, I might consider making
> uniter.Mode
> (which BTW should not really be exported) into an interface and each of the
> existing mode functions into a separate types.
>

Yeah; oddly enough, it was partly my imagining going in more-or-less that
direction (but implementing the modes in another package) that led to them
being written as exported.

However, I think the mode approach has outlived its usefulness. After a
couple of years, Modes are now either trivial or bloated; in ModeAbide in
particular, there are too many possible inputs and reactions to keep track
of them in one select loop. And it's becoming increasingly inconvenient to
depend on the golang scheduler; and, basically, we need an operation queue
that self-prioritises/compacts as events come in.

It won't be trivial -- in particular, we need to disentangle the
local-state storage from the operations that currently generate it -- but
the queue can be synchronous; it can be composed of smaller queues that
manage priority of closely-related hooks (as relation hooks are implemented
today); and it can actually be unit-tested in adequate detail. And the
event delivery might still not be beautiful, but I'm pretty sure we can do
better than the existing Filter if we don't constrain ourselves by
optimizing the interface for delivering events to mode loops.

Cheers
William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20150720/51caade2/attachment.html>