Uniter tests for update-status hook - BLOCKER

[William Reade]

On Mon, Jul 20, 2015 at 3:37 PM, Horacio Duran <horacio.duran at canonical.com>
wrote:The immediate bit:
>
> So, I agree we have a big elephant on the room and we might have all been
> looking the other way (most likely distracted by the pack of velocirraptors
> on the other side).
> We ought to sit and talk about this tech-debt negotiation, as any debt
> negotiation this takes a couple of rounds of discussion around a table,
> some shouting and a conclusion that might let none of us completely happy
> but will produce the best outcome in terms of reliability and functionality
> for the experience/service we are trying to provide here.
>

This misses the point. We should never reach the point where we have to
shout around tables, because we should be maintaining the code properly as
we work. Technical debt is a tool; when we need to deliver particularly
important user value fast, we can take on some debt to accelerate progress,
and that's super-powerful. But that should be a deliberate, knowing choice,
and it should be made in response to specific needs -- and *not* as a
habit, or a way to avoid embarrassment for underestimates by sacrificing
quality instead of scope or time.

In the immediate however, this is blocking master so Ill be working on a
> solution that solves the symptom at hand as we know this works in practice
> it is a matter of better defining the tests for now while we work ASAP in a
> better foundation for at least idle and whatever is built on top of it.
>

The best way to resolve the update-status problems is to *back out the new
update-status work*; and, for now, restore the previous (and somewhat
problematic, but tolerable) idle-status behaviour, and the basic 5-minute
update-status cadence as in 1.24. We can then rework that lot into a
deterministic form while otherwise preserving behaviour; and *then* branch
for update-status-on-queue-empty, from a reasonably solid foundation.

Anything else just keeps the update-status problems in everyone else's way
while we scramble; and it's hard to make smart decisions when you're
scrambling. And I'm not happy about backing this out either -- queue-empty
update-status is awesome -- but it's not worth the instability.

As a side note, we need to spread some education about the uniter, its
> innards and the design philosophy around it since much of the added code on
> it seems a result of just throwing a case into the select, see what it did
> and then accommodate to it (my very first approach included).
>

Please be aware, this isn't directed at you specifically, I just happen to
be replying to your email.

Documentation for the original hooks, their ordering guarantees, the
relation model, etc has existed here [0] for a very long time, and I have
made a point of directing people at it. I seem to hear a lot of people
saying "the uniter is hard to understand" but then demonstrating severe
unfamiliarity with the basics like "what hooks we're meant to run and when"
and "how units communicate within a relation". Some parts of that doc have
even been updated correctly as time passed. (Not all -- and ofc, mea culpa
for some of that. I'm not trying to pretend the documentation is perfect.)

But still... before you change the uniter, it is important to stop and
think thoughts like "what guarantees [1] do we currently make; what new
guarantees do we want to make as a result of this change; how do these use
cases interact and/or conflict; how can I resolve these interactions or
contradictions in a way that does not surprise the user".

Actually, scratch that: those are the questions you should be asking before
you change *any* component. Not knowing is fine; not knowing and not asking
and not reading either is, uh, not. (But writing useful things down in the
wiki, or expanding comments in difficult bits of code, is *awesome*.
Everyone do more of that please.)

FWIW, I will happily have detailed pre-implementation calls with anyone
about anything, *especially* regarding state and worker/uniter [2]; I just
appreciate a little bit of warning so I can manage occasional bursts of
uninterrupted hacking time.

Cheers
William


[0] https://github.com/juju/juju/blob/master/doc/charms-in-action.txt
...maybe it's rubbish? I'd love to make it better, but I seem to need
someone to tell me where it fails...

[1] Not thinking in terms of guarantees is a fundamental mistake: we can be
sure that *anything* that can go wrong *will* go wrong, sooner or later.
Code that works flawlessly on the happy path is about 5% of the full story;
the real value comes in the code that *only* makes guarantees it can keep,
even in the presence of a dedicated chaos monkey; and which fails safe and
recoverable when it can't make them.

[2] emerald in particular is very good about doing this, thank you all
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20150720/5190703b/attachment.html>