[00:34]  * thumper relocates to the coffee shop for lunch
[01:02] <wallyworld> axw: standup?
[01:48] <axw> wallyworld: which bug did you want me to check?
[01:49] <wallyworld_> axw: bug 1686696
[01:49] <mup> Bug #1686696: Subordinate units won't die until all principal relations are gone <juju:Triaged> <https://launchpad.net/bugs/1686696>
[01:49] <axw> okey dokey
[01:50] <axw> wallyworld: also I didn't get a travel email, FYI
[01:50] <wallyworld_> axw: yeah, it came to me, so maybe i need to send it on, will follow up
[02:10] <thumper> who knows most about proxies right now?
[02:29] <axw> wallyworld: how deep do you want me to go on this bug? it certainly seems like an issue to me
[02:30] <wallyworld_> axw: not too deep - just a sanity check that we agree that it needs fixing. babbageclunk can dive in... :-)
[02:30] <wallyworld_> i think it's a real issue too
[02:30] <wallyworld_> thumper: what did you want to know?
[02:31] <thumper> have a user behind proxies where bootstrap is getting stuck downloading agent tools
[02:31] <thumper> just wondering how much testing we have done of that situation
[02:33] <axw> thumper: burton-aus is having a similar issue with the vsphere provider in CI
[02:33] <axw> unresolved though
[02:33] <axw> so probably not helpful to you...
[02:34] <thumper> :)
[02:34] <thumper> balloons: something to add to our CI tests
[02:34] <thumper> balloons: proxied network installs
[02:37] <veebers> thumper: we currently have some proxy testing, although not sure off the top of my head the depths that it goes
[02:37] <thumper> hmm..
[02:38] <wallyworld_> thumper: i thought we had seen this issue a bit in the past and attempts had been made to make it work. but clearly somthing broke again
[02:38] <babbageclunk> thumper: I know a bit about proxy stuff, was helping with a maas testing issue to do with it.
[02:38] <balloons> thumper, add a card in the backlog, or I will tomorrow :)
[02:39] <babbageclunk> wallyworld_: take a look at: https://github.com/juju/juju/pull/7352?
[02:40] <wallyworld_> ok
[02:40] <babbageclunk> thanks!
[02:41] <wallyworld_> babbageclunk: thanks for fix, land that sucker
[02:42] <babbageclunk> sweet
[02:42]  * babbageclunk goes for celebratory run
[02:45] <thumper> um...
[02:45] <thumper> wallyworld_, babbageclunk: there is an issue there.
[02:46] <thumper> or is there...
[02:46]  * thumper thinks
[02:46] <thumper> no
[02:46] <thumper> I'm wrong
[02:46] <thumper> it's all good
[02:46] <wallyworld_> phew
[02:46] <axw> wallyworld: PTAL, I've responded to comments on https://github.com/juju/juju/pull/7346
[02:46] <wallyworld_> ok
[02:58] <wallyworld_> axw: i totally forgot about the initial event for all 3 watchers. doh. could you maybe just add a comment so the next dumb person doesn't wonder also
[02:58] <axw> wallyworld: sure
[03:45] <axw> wallyworld: could we leave the monday standup where it was? that's sunday for eric and heather, and it's a dropoff day for me
[03:45] <wallyworld_> ah right ok
[03:46] <axw> sorry would've said before, just didn't occur till later
[03:49] <wallyworld_> no worries
[05:04] <menn0> jam: standup?
[05:37] <babbageclunk> axw: did you have any thoughts about bug 1686696? I thought we couldn't remove subordinate units once they're deployed?
[05:37] <mup> Bug #1686696: Subordinate units won't die until all principal relations are gone <juju:Triaged> <https://launchpad.net/bugs/1686696>
[05:45] <wpk> jam: have you published your review? I don't see it..
[05:49] <axw> babbageclunk: the subordinate units do get removed when you remove *all* the relations to the subordinate app
[05:49] <axw> babbageclunk: ISTM that we should remove the subordinate units related to the app from which we remove the relation
[06:02] <axw> burton-aus: thanks for filing the bug
[06:08] <burton-aus> axw: no worries.
[09:59] <rogpeppe> some juju API client refactoring and some extra fallback logic: https://github.com/juju/juju/pull/7338
[12:30] <wpk>  https://github.com/juju/juju/pull/7353 trivial one, anyone?
[21:16] <thumper> morning
[22:13] <hml> wallyworld: here’s the pr for the arm64 bootstrap bug https://github.com/juju/juju/pull/7354
[22:13] <wallyworld> ok, thank you, looking in 5 after coffee
[22:32] <wallyworld> hml: see if my comments make sense to you
[22:32] <hml> wallyworld: looking now
[22:37] <hml> wallyworld: working on the revisions
[22:38] <wallyworld> ty
[22:38] <wallyworld> hml: i forgot to comment - there should be tests for the various combinations
[22:41] <hml> wallyworld: got it
[22:48] <hml> wallyworld: regarding changing DefaultBaseURL = metadataDir , a lot of other code expects it not to have tools at the end and use ToolsURL() to construct it.
[22:48] <hml> wallyworld: not a lot, but the users
[22:50] <hml> wallyworld: i’d have to double check on what happens if tools is already there on the URL
[22:50] <wallyworld> hml: right, so the check is just to see if what's passed in ends with /tools so as to see if we need to set the images path or not. the user is supposed to only pass in the top level dir but as we saw from the bug, they end up passing in /images so we just need to cater for that sort of scenario
[22:50] <wallyworld> and visa versa when they pass in something with /tools
[22:51] <wallyworld> we may then need to strip off the /tools before setting DefaultBaseURL
[22:51] <wallyworld> if that's what the downstream code expects
[22:52] <hml> wallyworld: so assume that if images or tools is that the end, the other isn’t expected
[22:52] <wallyworld> right
[22:52] <wallyworld> because that is the basis of the bug
[22:52] <wallyworld> they were passing in /images and we were setting tools dir
[22:53] <wallyworld> so we're expanding the behaviour to better match user intent
[22:53] <wallyworld> DWIM
[22:53] <hml> wallyworld: agreed
[23:29] <balloons> wallyworld, menn0, if you can have another quick look at https://github.com/juju/juju/pull/7350 and give +1 or -1?
[23:29] <wallyworld> ok
[23:29] <menn0> balloons: looking
[23:32] <wallyworld> balloons: there are still pyc files there?
[23:32] <menn0> balloons: done
[23:33] <wallyworld> balloons: also, we don't need bzrignore right? should be gitignore
[23:41] <menn0> balloons, wallyworld, thumper: balloons was right about trusty. we're still using MongoDB 2.4 there. if something in the controller or our tests doesn't work with 2.4 then that's a problem.
[23:42] <wallyworld> hmmmm
[23:44] <wallyworld> i guess CI needs to ensure we test controllers on trusty
[23:46] <menn0> wallyworld: which we do. the backup/restore tests use trusty controllers and I suspect a lot more tests do.
[23:46] <wallyworld> ok
[23:47] <wallyworld> and we would have controllers on xenial as well
[23:58] <babbageclunk> ha ha, I love the j-squad meeting names