Those workers below aren't the only ones. There's also minunits and peergrouper workers.
No-one does these things on purpose. Just last week I caught and rejected a pull request to introduce a new worker depending on state directly. People make mistakes. Perhaps we should introduce a test which fails if state is imported into any worker code. We have similar tests already for other forbidden imports. On 08/09/15 17:12, William Reade 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
