workers using *state.State

Dimiter Naydenov dimiter.naydenov at canonical.com
Thu Sep 10 11:59:26 UTC 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FWIW in Sapphire we did spend quite some time in the last few months
to migrate the "addresser", "cleaner", and "instancepoller" workers to
use the API instead of state.State directly.

Dimiter

On  9.09.2015 11:42, William Reade wrote:
> 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 <mailto: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.
> 
> 
> 
> 


- -- 
Dimiter Naydenov <dimiter.naydenov at canonical.com>
Juju Core Sapphire team <http://juju.ubuntu.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJV8XCdAAoJENzxV2TbLzHwdfgH/Au/6JBrrkr8t4LV5w8eebZN
3OUAojGL5egoK8wBXOmS4LYJeZ4FZWipkHVexdcmTOeRvER1x4hV/kFL18rrnPbw
sqoO0CbW+dF2byRigvelYMMgiZiaGcDALNVt5v2/gHAfj43S4RpfniNYs/nOvaeN
yoVaWTyn7zR9cKbSULZoq7s61NSyuMMiKPTb7gDKu6MSBRjqtM+OPNKOQUYZpgOp
UeQyAw2NYE9vG0PUgPyaZevaFzwTVae0Tcu3QoRZzqoU5vBiYxXyGA+BAr3EXo6e
ksYWbF/2NP+UZR67OPl6zqKz7vgpWCXuCbX+rU+xOh+34Ud6jOUPXKCdPyvCA7I=
=J1s1
-----END PGP SIGNATURE-----



More information about the Juju-dev mailing list