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 <[email protected]> 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. >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
