[00:04] <thumper> anastasiamac: ^^^ that is the first part of my fix
[00:04] <anastasiamac> thumper: looking ;)
[00:20] <anastasiamac> thumper: reviewed :D
[00:35] <axw> wallyworld: did the KVM/LXC image cache expire old images?
[00:36] <axw> I'm guessing not, since that would require some smarts in the server - and it was just a proxy IIRC
[00:36] <wallyworld> axw: no, was quite a simple implementation
[01:31] <wallyworld> axw: babbageclunk : standup?
[02:03] <babbageclunk> wallyworld: here's that bug: https://bugs.launchpad.net/juju/+bug/1679948
[02:03] <mup> Bug #1679948: juju bootstrap is failing in the MAAS CI lab  <juju:New> <https://launchpad.net/bugs/1679948>
[02:03] <wallyworld> TA
[02:08] <axw> wallyworld hml: got a call from oracle about my trial... did I miss anything?
[02:09] <axw> oh you're still there
[02:09] <wallyworld> axw: no, just explaining how build agent etc works
[02:09] <thumper> anastasiamac: thanks
[02:09] <thumper> anastasiamac: next one coming up shortly
[02:10] <anastasiamac> thumper: nps :D m looking forward to the sequel
[02:16] <wallyworld> veebers: sorry, caught up in meeting, will miss the QA catchup i think
[02:16] <veebers> wallyworld: nw
[02:53] <thumper> anastasiamac: https://github.com/juju/juju/pull/7233, +251 −730 (as long as you ignore the 217 files bit)
[02:54] <anastasiamac> thumper: wow... anything in particular to pay attention too? coz otherwise m going to hit the button with my eyes closed :D
[02:54]  * thumper looks for the files of interest
[02:55] <thumper> cmd/juju/commands/main.go
[02:55] <anastasiamac> thumper: ack
[02:56] <thumper> cmd/jujud/main.go
[02:56] <thumper> cmd/plugins/juju-metadata/metadata.go
[02:56] <thumper> that's it really
[02:57] <thumper> everything else is dealing with using cmdtesting from the juju/cmd package rather than juju/juju/cmd
[02:57] <thumper> and the rename of juju/juju/cmd/cmdtesting to juju/juju/cmd/cmdtest
[02:57] <anastasiamac> thumper: ack. looking -tyvm!!
[02:57] <thumper> The only thing left in the juju/juju/cmd/cmdtest now is some weird arse function about running a command with the dummy provider
[02:58] <thumper> can't fix everything at once
[02:59] <anastasiamac> thumper: agreed. lgtm'ed
[02:59] <thumper> ta
[03:12] <babbageclunk> wallyworld: Can you take a look at https://github.com/juju/juju/pull/7234
[03:12] <wallyworld> sure, i just need a quick bit to eat
[03:13] <babbageclunk> wallyworld: I need to pop out but after that can we chat about the changes needed for short-circuiting?
[03:13] <babbageclunk> wallyworld: cool cool
[03:16] <wallyworld> babbageclunk: sure, can do
[04:16] <wallyworld> babbageclunk: left some comments, happy to chat whenever
[04:16] <babbageclunk> awse, thanks
[04:16] <babbageclunk> looking now
[04:37] <anastasiamac> menn0: if you happen to find urself with nothing to do \o/ PTAL at my update of https://github.com/juju/juju/wiki/MgoPurgeTool with everything u've mentioned
[04:41] <mup> Bug #1492237 changed: juju state server mongod uses too much disk space <canonical-bootstack> <mongodb> <oil-2.0> <uosci> <juju:Won't Fix> <juju-core:Won't Fix> <https://launchpad.net/bugs/1492237>
[04:43] <jam> anastasiamac: "runaway transactions on apihostports or machines" could be lumped into cleaning up txn references from all documents
[04:43] <jam> at one point we had specific problems on a couple collections, but now we cleanup all of them
[04:43] <jam> (the newest one is model documents)
[04:43] <jam> I don't know if people care as much about the specific issues vs the category of issue, though
[04:44] <anastasiamac> oh jam, that the wording I did not touch :)
[04:44] <jam> Prunning I think is spelled Pruning
[04:44] <anastasiamac> ah, that one would be mine - anything misspelt cannot b menn0 :)
[04:44] <jam> I'm pretty sure pruning has to run on the primary
[04:44] <jam> compact needs to be run on secondaries
[04:45] <jam> we've also found that it isn't 100% compatible with Juju 1.18, though it is close
[04:45] <anastasiamac> jam: yeah, that is why is said juju 1.25.x :)
[04:45] <jam> mgopurge drops the db entirely for presence, and we can't do that, but you can drop the individual tables
[04:47] <mup> Bug #1492237 opened: juju state server mongod uses too much disk space <canonical-bootstack> <mongodb> <oil-2.0> <uosci> <juju:Won't Fix> <juju-core:Won't Fix> <https://launchpad.net/bugs/1492237>
[04:47] <menn0> anastasiamac: unfortunately I am famous for typos
[04:48] <menn0> jam: pruning can run anywhere I think (all writes go to the primary), but it's most efficient to run on the primary
[04:48] <anastasiamac> menn0: jam: fixed everything except does pruning need to/must run on primaries?
[04:48] <anastasiamac> k. i'll add that as a note too :)
[04:49] <jam> menn0: well, if it redirects all writes to the primary, are you running on a secondary? I'm not sure what guarantee we are opening the session in
[04:49] <jam> (strongly consistent auto redirects all requests to the master)
[04:49] <jam> which would mean you might be running the script on another machine, its still running on the primary
[04:50] <mup> Bug #1492237 changed: juju state server mongod uses too much disk space <canonical-bootstack> <mongodb> <oil-2.0> <uosci> <juju:Won't Fix> <juju-core:Won't Fix> <https://launchpad.net/bugs/1492237>
[04:53] <jam> anastasiamac: why did you mark https://bugs.launchpad.net/juju/+bug/1492237 as Won't Fix vs Fix Committed for 2.2 ?
[04:53] <mup> Bug #1492237: juju state server mongod uses too much disk space <canonical-bootstack> <mongodb> <oil-2.0> <uosci> <juju:Won't Fix> <juju-core:Won't Fix> <https://launchpad.net/bugs/1492237>
[04:53] <jam> though I suppose the other aspects are "configurable log" and "statuseshistory" would be the other 2 commits for 2.2
[04:53] <jam> and then what to do about the charm blob store
[04:54] <jam> esp. wrt JAAS cache where the admin of the db isn't the one whose data we are working with.
[05:01] <jam> anastasiamac: coming to https://hangouts.google.com/hangouts/_/canonical.com/discuss-roadmap?authuser=1 ?
[05:04] <menn0> anastasiamac: r u joining?
[05:05] <anastasiamac> sorry sorry got distracted by imprtant ppl
[05:12] <babbageclunk> wallyworld: take another look? https://github.com/juju/juju/pull/7234
[05:12] <wallyworld> babbageclunk: will do, just in yet another meeting, *sigh*
[05:12] <babbageclunk> wallyworld: ok, no worries :)
[05:14] <babbageclunk> wallyworld: running a test against GCE now - wasn't sure whether rebooting the machine was enough - wouldn't enter scope also happen in that case anyway?
[05:14] <wallyworld> babbageclunk: don't think so - scope entry is on the controller side
[05:15] <babbageclunk> ah right
[05:42] <wallyworld> babbageclunk: i'm multi-tasking - how did the GCE testing go?
[06:19] <wallyworld> axw: quick review if you have time? https://github.com/juju/juju/pull/7235
[06:19] <axw> wallyworld: sure
[06:19] <wallyworld> ty
[06:20] <wallyworld> bbiab after coffee run
[06:43] <jam> anastasiamac: I see, so we're not "imprtant ppl"... :,(
[06:45] <anastasiamac> jam: u r... but there is also a higher category of "very imprtant"
[06:46] <anastasiamac> :D
[06:50] <jam> anastasiamac: ah, I see. so priority inversion, unable to interrupt the 'imprtant' people to meet with the 'very imprtant' ones
[06:53] <anastasiamac> :)
[07:54] <babbageclunk> wallyworld: sorry, was afk.
[07:54] <wallyworld> no wuckers
[07:55] <babbageclunk> wallyworld: it looks like it didn't work because the bounced machine hasn't picked up its new public address - I guess a problem with the GCE provider?
[07:55] <babbageclunk> wallyworld: :(
[07:57] <wallyworld> babbageclunk: there's an instance address poller than runs but then backs off once the address is known. the agent is also suposed to report addresses from memory. i can't recall the specifics
[07:58] <wallyworld> but that's not for this PR
[07:58] <babbageclunk> wallyworld: hmm - I guess the agent wouldn't know that the machine's public address changed, right?
[07:58] <babbageclunk> wallyworld: so it would have to be the instance poller.
[07:59] <babbageclunk> wallyworld: Ok, I'll merge my PR anyway
[07:59] <wallyworld> babbageclunk: there's supposed to be an address poller in the agent i thought
[07:59] <wallyworld> but i could be wrong, will have to check
[07:59] <babbageclunk> wallyworld: but it would need to talk to the provider to find out the public address.
[08:00] <wallyworld> why?
[08:00] <wallyworld> the agent would poll the nics
[08:00] <wallyworld> on the machine
[08:00] <wallyworld> i guess it depends on how things are configured
[08:00] <wallyworld> maybe you're right
[08:01] <wallyworld> maybe the agent start up should trigger the instance poller
[08:01] <wallyworld> maybe that's already supposed to happen
[08:01] <wallyworld> so many questions
[08:06] <wallyworld> axw: i've pushed changes, too bad ParseDuration() doesn't support "days"
[08:07] <axw> wallyworld: yeah. we could always add another function that extends the syntax, but at least this way it's more flexible
[08:10] <axw> wallyworld: LGTM
[08:12] <wallyworld> axw: ty
[08:13] <wallyworld> will test again befor elanding
[08:13] <wallyworld> babbageclunk: i've added a card to ensure we remember to check for why rebooting an instance causing an address change is not being picked up by juju
[08:25] <babbageclunk> wallyworld: oh, it eventually did! Haven't had a chance to investigate - talking to the maas guy.
[08:26] <wallyworld> babbageclunk: that matches my understanding then, whew. the instance poller will wake up and do it. we just need to be smarted about triggering it after a reboot
[08:30] <mwhudson> axw: turns out that the TMPDIR-clearing antics are the dynamic loader's fault
[08:30] <mwhudson> (because there is a setuid executable in the chain of invocations when you run a snap)
[08:33] <axw> mwhudson: ah, right
[08:34] <wpk> jam: order does matter if you want to have something to test against :)
[08:40] <jam> wpk: I'm not worried about SortedValues as much as I am whether we need to preserve the *users* order
[08:41] <jam> wpk: and I believe it doesn't matter, so shoving it into a Set is fine, and the SortedValues is appropriate
[08:48] <wpk> jam: technically it's a set
[08:48] <wpk> jam: also, that's what proxyupdater has been always doing
[08:48] <jam> wpk: sgtm
[09:06] <babbageclunk> jam: I'm chasing this bug 1679948 with a guy from the maas team
[09:06] <mup> Bug #1679948: juju bootstrap is failing in the MAAS CI lab  <juju:New> <https://launchpad.net/bugs/1679948>
[09:07] <babbageclunk> jam: The controller looks like it's running fine, but the client can't connect to the api - we just see the Forbidden message in the log
[09:15] <babbageclunk> jam: connectivity seems fine, we can ssh from the client to the controller
[09:17] <babbageclunk> jam: and in the logs on the controller we can see the various workers connecting the the API as well, so I'm not sure why the client can't
[09:18] <jam> babbageclunk: are you able to wget against the controller?
[09:18] <jam> is the URL a valid uuid for a model?
[09:19] <babbageclunk> jam: gah, didn't think of just wgetting - I was trying to find a websocket client I could use
[09:20] <jam> it just tells you if you can open the socket
[09:20] <jam> you can also try "telnet host 17070" or whatever the exact prot is
[09:20] <babbageclunk> jam: yeah, will get in touch and try that
[09:24] <babbageclunk> jam: I guess telnetting to it would tell something even though it's not going to do the https handshake
[09:39] <jam> babbageclunk: you'll see the SSL headers come over
[09:39] <jam> babbageclunk: there is also "openssl s_client"
[09:39] <jam> which is 'telnet but for SSL'
[09:41] <babbageclunk> jam: found a websocket client code example that might be a useful test bed - just seeing how far I can get to pass in some JSON to login to the API and eg list the models.
[11:18] <menn0> jam: here's a PR that addresses one of the items we were discussing in today's call
[11:18] <menn0> https://github.com/juju/juju/pull/7237
[11:19] <jam> menn0: looking. what is cloud 'dev' ?
[11:20] <menn0> jam: just lxd with config for my local apt proxy and disabling auto apt upgrade
[11:21] <menn0> jam: ala https://github.com/juju/juju/wiki/Faster-LXD#suggested-juju-config-for-lxd-deployments
[11:22] <jam> sure, I have the same, just put it on 'lxd' itself
[11:22] <jam> menn0: https://github.com/juju/juju/pull/7237#pullrequestreview-32605432 lgtm, though in *my* opinion, if we're going to have '--no-switch' then we really should have '--switch'
[11:22] <jam> and I'm hesitant to add a short option
[11:22] <jam> we could live with just landing what you requested
[11:23] <jam> *proposed
[11:24] <menn0> jam: I don't understand why we would you have --switch? if there's already --no-switch.
[11:24] <menn0> jam: I was borderline on the short option but it seemed like the kind of thing that some people would want to do all the time
[11:24] <jam> menn0: so if you have "--dont-do-foo" it seems useful to have a "--do-foo" to invert it
[11:24] <jam> it may be that "--do-foo" is currently the default
[11:24] <menn0> jam: but if that's the default....
[11:24] <jam> but that doesn't let us change it
[11:25] <jam> *i* like the ability to be explicit, especially for things like scripts
[11:25] <menn0> if it's the default, most people won't use the option IMHO
[11:26] <menn0> and we can't really change the default (until 3.x anyway) for compatibility reasons
[11:27] <jam> menn0: its personally a pet peeve when there is an option but you can't explicitly select a behavior, as then you have to know what the default behavior is, instead of just being able to say "this is the behavior I want"
[11:27] <jam> that, however, is *my* opinion, so if you'd like a second opinion/consensus feel free to override/ask others
[11:28] <menn0> fair enough, i'll ask around next week
[11:28] <menn0> it's late and there's no particular rush to land this right now
[11:28] <jam> menn0: for example, in 'mgopurge' we have -ssl=false as how you disable it, but you can specify -ssl=true
[11:29] <menn0> yep, I guess so
[11:29] <menn0> on the flip side we already have -no-gui and --no-browser-login
[11:29] <menn0> on bootstrap