Re: workers using *state.State

On 9 September 2015 at 12:51, Tim Penhey wrote: > On 09/09/15 12:47, Menno Smits wrote: > > You missed another worker that needs updating: envWorkerManager. Its use > > of *state.State is a little less obvious. > > I had left that one off because I thought it only had the state instance > to pass

Re: workers using *state.State

On 09/09/15 12:47, Menno Smits wrote: > You missed another worker that needs updating: envWorkerManager. Its use > of *state.State is a little less obvious. I had left that one off because I thought it only had the state instance to pass on to other workers. But I guess it does need updating, so

Re: workers using *state.State

You missed another worker that needs updating: envWorkerManager. Its use of *state.State is a little less obvious. Ticket and card added: https://bugs.launchpad.net/juju-core/+bug/1493606 On 9 September 2015 at 12:43, Tim Penhey wrote: > On 09/09/15 12:36, Horacio Duran wrote: > > There is lazy

Re: workers using *state.State

On 09/09/15 12:36, Horacio Duran wrote: > There is lazy and there is also "I just based in that other worker" > which happens, I am the proud parent of statushistorypruner and a > rewrite is underway too, sorry. Don't get me wrong, lazy developers are generally good. We try to find the simplest th

Re: workers using *state.State

There is lazy and there is also "I just based in that other worker" which happens, I am the proud parent of statushistorypruner and a rewrite is underway too, sorry. On Tuesday, September 8, 2015, Tim Penhey wrote: > On 09/09/15 11:22, Andrew Wilkins wrote: > > On Wed, Sep 9, 2015 at 6:14 AM Ian

Re: workers using *state.State

On 09/09/15 11:22, Andrew Wilkins wrote: > On Wed, Sep 9, 2015 at 6:14 AM Ian Booth > wrote: > > 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

Re: workers using *state.State

On Wed, Sep 9, 2015 at 6:14 AM Ian Booth wrote: > 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. Pe

Re: workers using *state.State

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 fa

Re: workers using *state.State

Hey Will, FWIW, I'm responsible for 2 of them - dblogpruner and txnpruner. They were created before I'd ever heard anything about workers not using *state.State directly, certainly before the recent push to clean such workers up. They're not all that new and weren't created in violation of explici

workers using *state.State

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.) T