[00:57] <wallyworld> axw: no, we use the normal provider
[02:22] <thumper> axw: I don't suppose you know how to configure log forwarding?
[02:23] <axw> thumper: you need to set logforward-enabled=true, syslog-host=<host>, syslog-ca-cert=<pem-encoded-ca-cert>, syslog-client-cert=<pem-encoded-client-cert>, syslog-client-key=<pem-encoded-client-key>
[02:24] <axw> so easy ;)
[02:24] <thumper> in the model config?
[02:24] <axw> thumper: yep
[02:24] <axw> thumper: in the controller model config
[02:24] <axw> thumper: not to be confused with controller config...
[02:24] <thumper> hazaah
[02:24] <thumper> axw: I was thinking... we could make this change for log forwarding completely transparent...
[02:25] <thumper> by just making the worker model dependent and not one for the controller
[02:25] <thumper> and still have the tailer just deal with a single model
[02:26] <axw> thumper: yes we could. we'd just need to use model config defaults to ensure all models get the same syslog-foo config
[02:26] <thumper> or... transparently have that worker just get the config from the controller
[02:26] <thumper> and don't worry at this stage about getting it from the model config for *that* model
[02:27] <thumper> it is a bit ick, but not terrible
[02:29] <axw> thumper: what I want eventually is for different models to log to the relevant cloud log sink. so a GCE model should go into the stackdriver logging for that model's project. should be able to do something similar for Azure (though I can't quite figure out the API)
[02:29]  * thumper nods
[02:29] <axw> thumper: that would allow JAAS users to get their model logs
[02:29] <axw> without going through debug-l;og
[02:29] <thumper> sounds very useful
[02:30] <axw> thumper: it would be useful to have controller-wide config too though. so maybe a hierarchy.
[02:30]  * thumper nods
[02:30] <thumper> sounds like we should start a spec outlining the work
[02:31] <axw> should also run it by IS and JAAS, I'm sure they'll have some things they'd want
[02:31] <thumper> yeah
[02:31] <thumper> for the future work for sure
[02:31] <thumper> for the "let's not screw jaas"
[02:31] <thumper> I'm all for minimal exposure to the way it works now
[02:31] <axw> yup
[02:33]  * thumper may have found the next piece of work for babbageclunk
[02:33] <thumper> babbageclunk: call when you are around?
[03:10] <axw> wallyworld: have you snapped juju recently? it wants to use golang-go, which is go-1.6...
[03:12] <axw> hmm maybe it doesn't matter
[03:32] <babbageclunk> thumper: back, sorry, went for a run
[03:32] <thumper> gee, wouldn't want to run here today
[03:32] <thumper> it is wet and cold
[03:32] <thumper> getting very cold
[03:32] <thumper> like 5° cold
[03:32] <thumper> babbageclunk: hangout?
[03:33] <babbageclunk> beautiful day for a run here, cold and sunny and windy
[03:33] <thumper> babbageclunk: more stuff https://hangouts.google.com/hangouts/_/canonical.com/stuff
[05:38] <babbageclunk> wallyworld: can a relation change from being container-scoped to global-scoped? Maybe if there's charm upgrade? Trying to decide whether it's safe to cache decisions.
[06:23] <wallyworld> babbageclunk: i don't think so, no
[06:52] <rogpeppe> axw: saw my name mentioned earlier - did my recent changes break anything?
[06:52] <axw> rogpeppe: not sure, wallyworld said something about some cert related failures
[06:52] <wallyworld> rogpeppe: i sent an email
[06:53] <rogpeppe> wallyworld: ah, thanks
[06:53] <wallyworld> it appears it may have
[06:53] <wallyworld> not 100% sure
[06:54] <rogpeppe> wallyworld: are those errors happening every time?
[06:55] <wallyworld> not sure, there had only been one or two test runs post the landing that i had checked this morning
[06:58] <rogpeppe> wallyworld: hmm, it definitely isn't happening every time. weird.
[06:58] <rogpeppe> wallyworld: it's definitely the kind of area that *could* have been affected by my change
[06:58] <rogpeppe> wallyworld: but i'd expect it to be deterministic
[06:58] <wallyworld> yeah. it's plausible the pR and failures are related but not certain
[06:59] <wallyworld> i looked at the test runs just prior to the landing and couldn't see the failures there
[06:59] <wallyworld> but hard to draw a conclusion when it is intermittent
[06:59] <rogpeppe> wallyworld: yeah
[07:00] <wallyworld> i was thinking something may jump out at you
[07:00] <wallyworld> it's not an area i have expert knowledge in
[07:06] <rogpeppe> wallyworld: nothing's jumping out so far
[07:06] <wallyworld> joy
[07:16] <rogpeppe> wallyworld: we'll have to see if more of those kind of errors happen
[07:17] <wallyworld> yeah, need a few runs to gauge the depth of the issue
[07:17] <rogpeppe> wallyworld: in http://juju-ci.vapour.ws/job/github-check-merge-juju/1087/artifact/artifacts/grant.log there's at least one suspicious-looking error after the cert error
[07:17] <rogpeppe> 22:53:50 ERROR juju.tools.lxdclient client_instance.go:267 while removing instance "juju-85ed71-0": Failed to destroy ZFS filesystem: cannot open 'lxd-pool/containers/juju-85ed71-0': dataset does not exist
[07:17] <rogpeppe> wallyworld: so perhaps the cert error is usual
[07:19] <wallyworld> maybe, could be a timing issue
=== frankban|afk is now known as frankban
=== MmikeM is now known as Mmike
[08:42] <wallyworld> axw: a small PR, quick review? https://github.com/juju/juju/pull/7365
[08:43] <axw> wallyworld: sure, just a minute
[08:50] <axw> wallyworld: swap you https://github.com/juju/juju/pull/7366 ?
[08:50] <wallyworld> ok
[08:51] <wallyworld> axw: those pyc files were supposed to be removed already!
[08:52] <axw> wallyworld: I think they were removed in one directory but not the other
[08:52] <axw> anyway, added to gitignore so they won't sneak back in
[08:52] <wallyworld> 2 files is better than 108 :-)
[08:54] <wallyworld> axw: lgtm, will be good to see those tests passing again
[08:59] <axw> wallyworld: to save a roundtrip, my reply to your Q: "Why? ssh.Client.Command documents the argument as taking the syntax [user@]host. It shouldn't be needed."
[09:01] <wallyworld> axw: ok, no worries, i just thought it made it more obvious to the reader in the restore code. but i'm totally +-0 , ie no care factor either way
[09:02] <axw> wallyworld: if someone gets surprised they can add it back in :)
[09:07] <wallyworld> axw: i called it "cloudProviders" becuase it returns both addable and non-addable ones in 2 separate slices
[09:08] <axw> wallyworld: but the result is "providers", and "unsupported"
[09:08] <axw> wallyworld: cloudProviders+providers+unsupported doesn't tell me what it does
[09:08] <wallyworld> yeah, i just reused the previous var names, i can change to supported and unsupported
[09:09] <axw> no biggie, just not a super useful name when you're out of context
[09:09] <wallyworld> yeah, i'll come up with something
[09:10] <wallyworld> there's also a test isolation issue too from what was there already :-/
[09:10] <wallyworld> in the credential related suites somewhere. need to fix that too
[09:32] <wpk> Q: is it OK to remove API that's used only internally, by worker?
[09:37] <babbageclunk> wpk: I think the problem is that the controller might be running a more recent version of jujud than the agents, so they might still try to talk to the removed API/
[09:38] <babbageclunk> wpk: Oh, hang on - is it used by a worker in the unit or machine agents, or only in the model agent?
[09:41] <babbageclunk> wpk: I think in the latter case it's fine.
[09:48] <wpk> only in model agent
[09:48] <wpk> (discoverspaces worker)
[12:13] <rogpeppe> anyone know if the old juju reviews are still online? e.g. http://reviews.vapour.ws/r/1609
[12:34] <babbageclunk> rogpeppe: no, I think they turned them off a few weeks ago
[12:34] <rogpeppe> babbageclunk: oh
[12:34] <rogpeppe> babbageclunk: i think that's a really bad idea
[12:35] <rogpeppe> babbageclunk: they're actually a crucial part of the history of the project
[12:35] <babbageclunk> rogpeppe: I know - just after it happened I wanted to find something that I remember discussing in a review.
[12:35] <rogpeppe> babbageclunk: commit messages are often cursory at best
[12:35] <rogpeppe> babbageclunk: can we try getting them turned back on again?
[12:36] <babbageclunk> rogpeppe: yeah, I'll mention it to Tim
[12:36] <rogpeppe> babbageclunk: thanks
[12:36] <babbageclunk> (I mean, I assume they've kept the data!)
[12:36] <babbageclunk> :o
[12:38] <rogpeppe> babbageclunk: if they haven't, i'll be very unhappy
[12:38] <babbageclunk> I'll pass that on too
[12:40] <rogpeppe> babbageclunk: :)
=== frankban is now known as frankban|afk
[19:00] <balloons> hml, can I get a review of https://github.com/juju/juju/pull/7362?
[19:00] <hml> balloons: looking
[19:02] <hml> balloons: ha - i hate assuming anything… but… that’s a lot of files.  :-)
[19:03] <balloons> hml, :p It's akin to the PR I mention.. It's more or less dumping in the code from the old repos into juju
[19:03] <balloons> hml, there's one more for packaging, once I complete it :-)
[19:04] <hml> balloons: figured… i’ll go with assume this time if that’s okay with  you?  or do you want a sanity check?
[19:04] <balloons> hml, i don't just want to blind push things, hence the PR. So yes, a quick sanity check is most appreciated
[19:04] <hml> balloons: sanity checking now
[19:05] <balloons> I had to tweak the history on this import, so make sure it's clean for you
[19:08] <hml> balloons: where is the origin repro - haven’t mastered finding them in launchpad yet
[19:10] <balloons> hml, ahh, right. https://code.launchpad.net/~juju-qa/juju-ci-tools/repository
[19:10] <hml> balloons: ty