workers using *state.State

Tim Penhey tim.penhey at canonical.com
Wed Sep 9 00:33:04 UTC 2015


On 09/09/15 11:22, Andrew Wilkins wrote:
> On Wed, Sep 9, 2015 at 6:14 AM Ian Booth <ian.booth at canonical.com
> <mailto:ian.booth at canonical.com>> 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.
>     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.
> 
> 
> +1. I was thinking the same thing, and eventually that test should be
> increased to other packages too.

Let's be honest, developers are lazy. When under pressure to land
things, they go and look for the simplest way to get something done.

The problem has been that we didn't shout loud enough early enough that
there were to be "NO MORE STATE WORKERS", and what's more, making it a
priority to change the existing ones to api workers.

In case any one missed it, "NO MORE STATE WORKERS". Onyx will take the
dblogpruner and txnpruner as we added those, and Menno already mentioned
this.

Bugs have been filed for the five workers using *state.State directly,
and have been added to the tech-debt kanban board.

https://canonical.leankit.com/Boards/View/116651667#workflow-view

Tim



More information about the Juju-dev mailing list