workers using *state.State

[William Reade]

Hey all

I'm sorry for the unnecessarily harsh tone in the OP, which was absolutely
not called for. Thank you all for stepping up to address it regardless.

I would like to calmly state that `doc/architectural-overview.txt` -- more
than a year old -- does state that all workers, whatever agent they're in,
should use the API server; and that we were all actively working on
api-everywhere not *that* long before then, so I am genuinely
surprised/saddened that our institutional knowledge didn't catch and
correct any of these before I threw a tantrum in person.

FWIW, I think that envworkermanager's *current* situation is justifiable:
IIRC the machine agent still needs the state conn to set up the singular
worker, and I suspect there are other subtler threads in play too. That's
not to say it *should* be doing that; but it is just invoking the general
run-env-workers code that pre-existed in the single-env agent code, and we
need to do more agent work before we can fully extract that dependency.

Cheers
William

On Tue, Sep 8, 2015 at 9:12 AM, William Reade <william.reade at canonical.com>
wrote:

> People keep writing them, in defiance of sane layering and explicit
> instructions, for the most embarrassingly trivial tasks
> (statushistorypruner? dblogpruner? txnpruner? *all* of those can and should
> pass through a simple api facade, not just dance off to play with the
> direct-db-access fairies.)
>
> There is no justification for *any* of those things to see a *state.State,
> and I'm going to start treating new workers that violate layering this way
> as deliberate sabotage attempts. Leads who have overseen the introduction
> of those workers, sort it out.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20150909/dc2f701c/attachment.html>