[00:09] <alexisb> thumper, can you please do the technical reviews on wallyworlds list-clouds and list-regions PRs
[00:11] <thumper> sure
[01:32] <menn0> wallyworld or thumper: here's the "juju enable-ha" improvement: https://github.com/juju/juju/pull/6421
[01:32] <wallyworld> thumper: thanks for review, i've updated list-regions pr
[01:32] <wallyworld> looking
[01:40] <wallyworld> menn0: done. i also just wanted to make sure you tested using an rc3 client to check the model facade call works still
[01:41] <menn0> wallyworld: good call, will do
[01:59] <menn0> wallyworld: rc3 client works as expected although there are some errors due to unqualified user names: http://paste.ubuntu.com/23305923/
[01:59] <menn0> wallyworld: is this ok?
[02:01] <wallyworld> menn0: those errors should not come up in practice for other clients. the main takeaway is tha the enable ha call worked. the error is because the 2.0 server returned a user without @local which rc3 client did not understand
[02:02] <menn0> wallyworld: yep that's what I figured. just wanted to check with you that that's expected. all good. merging now.
[02:02] <menn0> (other issues fixed)
[02:02] <wallyworld> awesome ty
[02:02] <wallyworld> menn0: if you are stuck for work, i have a small improvement i can pass on. not sure what you have in your plate
[02:03] <menn0> wallyworld: I was going to tackle that not-so-intermittent cert update test failure which was introduced yesterday
[02:03] <wallyworld> ok
[02:03] <menn0> wallyworld: but what else do you have?
[02:03] <anastasiamac> wallyworld: menn0: thumper: I feel like bug 1631438 is not for point release (2.0.1) but for minor (2.1.0) since it inverts current behavior? agree?
[02:03] <mup> Bug #1631438: Switch default behaviour of 'gui' w.r.t. browser <juju:New> <https://launchpad.net/bugs/1631438>
[02:03] <anastasiamac>  i need for executive 2nd opinion :D
[02:04] <wallyworld> menn0: easier via quick hangout to give context
[02:04] <wallyworld> standup?
[02:04] <menn0> wallyworld: see you there
[02:05] <menn0> anastasiamac: yep, that seems like more of a 2.1 thing
[02:05] <anastasiamac> menn0: u r awesome \o/
[02:07] <thumper> menn0, anastasiamac: hmm... I'm not so certain, given that it is a very 2.0 thing
[02:08] <thumper> personally it isn't something that I've had to deal with yet
[02:08] <thumper> and I feel that most others won't have hit it either
[02:08] <thumper> however it is very late in the day to be changing this
[02:08] <anastasiamac> thumper: i can propose a change if we are just talking about code.. dunno who it'll break.. considering 2.0.0 is freezing soon, there are only couple of hrs eft really..
[02:08] <thumper> my preference is to change nothing
[02:08] <anastasiamac> left*
[02:09] <thumper> I think I talked myself out of saying we should change now
[02:09] <anastasiamac> thumper: mine too... hence 2.1.0
[02:09] <anastasiamac> :D
[02:12] <anastasiamac> thumper: since I have u... isn't this a dupe of the one u did last week? https://bugs.launchpad.net/juju/+bug/1576342
[02:12] <mup> Bug #1576342: `juju status` should show leadership primitives <juju-release-support> <leadership> <status> <tech-debt> <juju:Triaged> <https://launchpad.net/bugs/1576342>
[02:13] <thumper> yes, fixed the bug
[02:14] <anastasiamac> thumper: \o/
[02:19] <mup> Bug #1632159 opened: juju 1.25.6 HA - Causing unit state issues. <canonical-bootstack> <juju:Incomplete> <juju-core:Incomplete> <juju-core 1.25:Incomplete> <https://launchpad.net/bugs/1632159>
[02:29] <wallyworld> thumper: list-regions PR? you happy with it now?
[02:35] <thumper> getting there, just dropped kiddo down to BJJ
[03:05] <anastasiamac> wallyworld: PTAL - https://github.com/juju/juju/pull/6422 thank you for the wording
[03:06] <wallyworld> give me a minute
[03:06]  * anastasiamac is very giving today 
[03:06] <anastasiamac> :D
[03:40] <wallyworld> thumper: i added details to regions for yaml and json because in general with juju, yaml and json can provide extras not ordinarily excluded from list. i realise show-cloud can be used, but my thinking was 1. that gives more than just region details, 2. I wanted to not have 2 commands to present region info (it's more natural for the user to flip output format for the regions command). I originally didn't have yaml or json because
[03:40] <wallyworld> just having []string for those didn't seem to pay its way so adding those formats I wanted to make it worth it
[03:41] <wallyworld> s/excluded/included
[03:42] <thumper> ok\
[05:10] <wallyworld> anastasiamac: not sure if you might have time to review the table header changes? https://github.com/juju/juju/pull/6423
[05:45] <anastasiamac> wallyworld: looking
[05:48] <wallyworld> ta
[06:01] <anastasiamac> nps. let me know when u want a stamp :)
[06:07] <wallyworld> anastasiamac: thanks for picking up those things i missed, i think it's good now?
[06:08] <anastasiamac> looking
[06:11] <wallyworld> anastasiamac: gotta run to do school pickup, if it's ok, can you $$merge$$ for me?
[06:12] <wallyworld> bbiab
[06:12] <anastasiamac> wallyworld: run coz I think "paylod class" needs to b changed too...
[06:12] <anastasiamac> k \o/
[06:12] <anastasiamac> i'll finish another review by the time u r back
[06:31] <wallyworld> anastasiamac: ty, fixed that last one
[06:32] <anastasiamac> wallyworld: \o/
[08:17] <hoenir> it's the same rule that one two +1 = $$merge$$ no?
[08:18] <babbageclunk> Hey, thumper, can I bug you for a quick opinion?
[08:18] <thumper> sure
[08:18]  * thumper is online to talk to uros
[08:18] <hoenir> if that rule is the same, could someone take a look on my latest PR? https://github.com/juju/juju/pull/6414
[08:18] <babbageclunk> Ah ok - no worries if you're busy
[08:19] <thumper> babbageclunk: not busy, he isn't around
[08:19] <babbageclunk> consolation chat!
[08:19] <hoenir> let me know if I have something to improve even further or it's safe to merge.
[08:19] <thumper> hoenir: to be honest, we probably won't be looking at things for a few days as we prep for 2.0 GA
[08:19] <thumper> hoenir: we won't merge it until after GA
[08:19] <thumper> bug fixes only just now
[08:19] <thumper> GA is Thursday, US time
[08:20] <thumper> so soon
[08:20] <hoenir> thedac, GA? what is GA? could you explain a little more please? and thanks for the response
[08:20] <babbageclunk> thumper: So I've worked out the remaining goroutine leaks - they're the read- and write-loops of http transports created by the lxd provider.
[08:20] <hoenir> GA stands for?
[08:21] <thumper> general availability
[08:21] <thumper> so the full 2.0 release
[08:21] <thumper> no more release candidates
[08:21] <dimitern> it's finally come to that..
[08:21] <hoenir> thumper, thanks for clearing this up, I should ping here before the GA release.
[08:21] <thumper> o/ dimitern
[08:22] <thumper> probably just after :)
[08:22] <dimitern> hey thumper :)
[08:22] <hoenir> thumper, thanks a lot !
[08:22] <babbageclunk> thumper: If I disable keepalives they go away, but that's probably bad.
[08:22] <thumper> hmm
[08:22] <thumper> how long is the keep alive set for?
[08:23] <thumper> can we just tweak that?
[08:23] <babbageclunk> No, they don't timeout
[08:23] <thumper> and is it just lxd that we leak?
[08:23] <thumper> oh
[08:23] <babbageclunk> Probably not
[08:23] <thumper> at all?
[08:24] <babbageclunk> Actually, I'll try putting a timeout in to see what happens. Would be easier than adding a .Close to EnvironProvider.
[08:24] <thumper> where does the http transport live?
[08:25] <babbageclunk> inside the lxd client, which is in the lxd provider.
[08:25] <thumper> and does the code create a new transport if the old has gone?
[08:26] <babbageclunk> I think when a new model added is we create a new client/new transport.
[08:26]  * babbageclunk yoda'd
[08:26] <thumper> heh
[08:27] <babbageclunk> The docs say we should keep one http.Client to avoid leaking - I think the problem is that we create a new one for each lxd client.
[08:27] <thumper> hmm...
[08:27] <babbageclunk> So I could contrive to pass it in somehoe
[08:28] <babbageclunk> uh, somehow
[08:28] <thumper> that sounds like a good idea
[08:29] <babbageclunk> The other option would be to call .CloseIdleConnections which will stop the loops - but that probably requires EnvironProvider.Close.
[08:29] <babbageclunk> I'll try injecting the http client in from further up.
[08:30] <babbageclunk> ok thanks!
[08:30] <thumper> np
[08:31] <babbageclunk> had fun mangling the stdlib to work out where the leak was coming from.
[08:32] <babbageclunk> hey dimitern, how was Florence?!
[08:33] <dimitern> babbageclunk: awesome! :) and all of Tuscany in general - better than Rome for sure hehe
[09:49] <babbageclunk> menn0: So it turned out that the leaked connections are from the lxd clients inside environs.
[09:49] <babbageclunk> menn0: also, hi!
[09:49] <menn0> babbageclunk: hi :)
[09:50] <menn0> babbageclunk: ok, interesting. easily fixable?
[09:51] <babbageclunk> menn0: Well, setting IdleConnTimeout in the transport when creating the http client works. I'm going to talk to the lxd people to see if they mind doing that. Do you think there'd be a downside to just doing that all the time?
[09:52] <babbageclunk> menn0: Or should it be configurable?
[09:52] <menn0> babbageclunk: depends if we expect to have connections not doing anything for a long time I guess
[09:52] <menn0> babbageclunk: configurable might be best
[09:53] <babbageclunk> menn0: it'll reopen them if they timeout and there's another request - it's purely a performance thing.
[09:54] <menn0> babbageclunk: ok, in that case, I don't see any downside, especially if the timeout is a few minutes or something
[09:57] <babbageclunk> menn0: Cool - I'll discuss it with Stephane and see if he has any objections.
[09:57] <babbageclunk> menn0: Thanks!
[10:04] <menn0> babbageclunk: np. nice work figuring it out.
[10:08] <menn0> babbageclunk: reivew please: https://github.com/juju/juju/pull/6425
[10:08] <menn0> review even
[10:08] <menn0> I'm off for now
[10:08] <menn0> so no rush
[10:08]  * menn0 is hoping he can still land this before the release branch
[10:09] <babbageclunk> menn0: I can look at it quickly now if you want?
[10:09] <menn0> babbageclunk: no need. I still need to QA the changes with MAAS.
[10:10] <babbageclunk> menn0: ah, ok
[10:11] <menn0> babbageclunk: just updated the description to show what the new output looks like
[10:11] <menn0> the change is the last line
[10:12]  * menn0 is exhausted
[10:12] <menn0> babbageclunk: good night
[10:12] <babbageclunk> menn0: night!
[10:34] <mgz> jamespage: bug 1580418
[10:34] <mup> Bug #1580418: Cached local charms should be deleted when their service is removed <juju:Fix Released by wallyworld> <juju-core:Fix Released by wallyworld> <juju-core 1.25:Fix Released by wallyworld> <https://launchpad.net/bugs/1580418>
[10:41] <jamespage> mgz, ta
[11:03] <rick_h_> dimitern: running a sec late
[11:03] <rick_h_> dimitern: omw
[11:08] <rick_h_> dimitern: ok, ping if you're around later
[11:08] <dimitern> rick_h_: oops sorry - omw
[12:01] <voidspace> dooferlad: ping
[12:02] <dooferlad> voidspace: pong
[12:02] <dooferlad> voidspace: sorry, I have been in meetings for the last 24 hours
[12:02] <voidspace> dooferlad: ouch :-)
[12:02] <dooferlad> voidspace: I guess you want me to look at some code!
[12:02] <dooferlad> voidspace: it's fine
[12:03] <voidspace> dooferlad: please, it's already merged - but it should have had a follow up review
[12:03] <dooferlad> voidspace: in one now
[12:03] <voidspace> dooferlad: https://github.com/juju/juju/pull/6419
[12:03] <voidspace> dooferlad:  if there are changes needed I'll do a follow up
[12:03] <voidspace> dooferlad: when you have time - thank you very much!
[12:03] <dooferlad> voidspace: thanks, will do
[12:10] <voidspace> mgz: ping
[12:21] <rick_h_> dooferlad: did you get anywhere with the test failures in your PR https://github.com/juju/juju/pull/6406 ?
[12:33] <dimitern> dooferlad, voidspace, frobware, babbageclunk: I'd appreciate a review on https://github.com/juju/juju/pull/6426 guys - needed to fix bug 1616098
[12:33] <mup> Bug #1616098: Juju 2.0 uses random IP for 'PUBLIC-ADDRESS' with MAAS 2.0 <4010> <cpec> <juju:In Progress by dimitern> <https://launchpad.net/bugs/1616098>
[12:35] <perrito666> morning
[12:35] <voidspace> perrito666: o/
[12:35]  * dimitern steps out for <1h
[12:35]  * voidspace launches 30 containers and goes for coffee
[12:36] <voidspace> mgz: ping again if you're around
[12:36] <anastasiamac> perrito666: hi :D
[12:55] <mgz> voidspace: yo
[13:10] <rogpeppe1> natefinch: i replied to https://github.com/juju/utils/pull/245 if you wanna take another look
[13:26] <lazyPower> well, it was really contrived and took some effort on my part, but i found a way to break the juju controller in a way that i dont know how to recover from
[13:26] <lazyPower> so, let me check some assertions first before i label it as such -   does the juju controller probe interfaces on the host and add those to the controller config? specifically the juju-db service?
[13:27] <natefinch> rogpeppe1: cool
[13:36] <dooferlad> voidspace: have looked at your branch - no issues from me
[13:37] <dooferlad> rick_h_: there was a Windows build failure. I didn't have a Windows VM around so I have been setting that up. It should be a case of providing a stub for Windows, but I don't want to code by throwing changes at the merge bot!
[13:37] <rick_h_> dooferlad: ok, just making sure we're on top of it since today is the last day to get code in for GA
[13:37] <rick_h_> dooferlad: so want to make sure we can get this change in
[13:37] <mgz> you can also just ssh into the ci windows machine and build stuff there
[13:38] <dooferlad> rick_h_: we will be lucky to.
[13:38] <dooferlad> mgz: details?
[13:39] <mgz> dooferlad: in the cloud-city branch
[13:39] <dooferlad> mgz: ohh, thanks!
[13:45] <voidspace> dooferlad: cool, thanks
[14:01] <rick_h_> katco: dimitern frobware dooferlad ping for standup
[14:01] <rick_h_> mgz: ^
[14:01] <mgz> rick_h_: I'm deep in rebuilding packages so don't want to reboot for ho
[14:02] <mgz> can give update here
[14:04] <dimitern> omw
[14:06] <babbageclunk> alexisb: ping?
[14:15] <dimitern> frobware: interestingly port 49151 is indeed unreachable on windows2012r2, but wininit.exe does listen on 49152-49159
[14:16] <frobware> dimitern: heh
[14:16] <voidspace> macgreagoir: we have a parent-teacher thing, but when I'm back from that I'll grab a review
[14:17] <macgreagoir> voidspace: Cheers!
[14:18] <rick_h_> mgz: anything you can do to help voidspace and his vsphere connection woes is <3 so we can validate this isn't a bigger 2.0 issue.
[14:18] <rick_h_> mgz: understand on the packaging and thanks for pushing through on that
[14:18] <rick_h_> dimitern: heads up this is showing conflicts now: https://github.com/juju/juju/pull/6426
[14:18] <rick_h_> dimitern: oh, nvm...read that too fast heh
[14:19] <rogpeppe1> here's a PR that fixes this critical juju bug: https://bugs.launchpad.net/juju/+bug/1631449. a review would be much appreciated please: https://github.com/juju/juju/pull/6427
[14:19] <mup> Bug #1631449: External users don't have access to models unless everyone@external is granted <juju:Incomplete> <https://launchpad.net/bugs/1631449>
[14:20] <mgz> rick_h_: gotcha, thanks
[14:36] <alexisb> perrito666, can you review rogpeppe1 PR
[14:36] <perrito666> sure I can, havent seen his message sorry
[14:38] <katco> macgreagoir: +1 on your pr
[14:38] <macgreagoir> katco: woo hoo! :-)
[14:38] <macgreagoir> Cheers
[14:39] <katco> macgreagoir: great job sticking with it! i think we got it to a much better place
[14:39] <macgreagoir> Thanks for the help.
[14:55] <rogpeppe1> perrito666: thanks
[14:56] <rogpeppe1> katco: would you be able to take another look at https://github.com/juju/juju/pull/6407 ? i've addressed the most significant issues but i haven't added fixes for unrelated tests.
[14:57] <katco> rogpeppe1: yes sure... will be just a bit but i will get to it today
[14:57] <katco> rogpeppe1: sorry for the wait
[14:57] <rogpeppe1> katco: thanks
[14:57] <katco> rogpeppe1: and thanks for the discussion
[14:57] <rogpeppe1> katco: np
[15:24] <perrito666> rogpeppe1: I am not completely sold on the allow model access thing, what kind of access are you allowing?
[15:24] <rogpeppe1> perrito666: if you've been granted permission to a model, you get access to that model
[15:25] <rogpeppe1> perrito666: even if you haven't got any access rights to the controller itself
[15:34] <dooferlad> voidspace / dimitern / frobware / babbageclunk: https://github.com/juju/juju/pull/6406 has been updated to exclude LXD code on Windows. The rest of the code already has a +1.
[15:34] <babbageclunk> dooferlad: looking
[15:34] <dooferlad> rick_h_: maybe that container fix will land after all... ^^
[15:35] <rick_h_> dooferlad: oooh
[15:46] <dimitern> rick_h_: it seems I won't manage to fix the public address bug tonight - as discussed with frobware, more detailed and specific connection checker tests are needed
[15:46] <dimitern> rick_h_: but that should be OK, right? I mean even once in GA mode we can still fix bugs?
[15:46] <rick_h_> dimitern: ok, yes we can fix bugs but we're not going to be doing weekly releases now
[15:46] <rick_h_> dimitern: so it'll be some time before a follow up and such
[15:47] <rick_h_> dimitern: that's why my push to get things in so that users don't feel stuck as much as possible, but we do what we can
[15:47] <rick_h_> dimitern: right fix > quick fix
[15:47] <dimitern> rick_h_: +100
[15:47] <dimitern> :)
[15:48] <dimitern> ok then, cheers rick_h_
[16:03]  * rick_h_ goes to get lunch
[16:10] <redir_afk> new kernel bbiam
[16:28] <frobware> voidspace: what was the other 'thing' you changed for LXD? I have the examples from bug #1631038 but have since close the HO chat...
[16:28] <mup> Bug #1631038: Need /etc/sysctl.d/10-juju.conf <juju-release-tools:Triaged> <https://launchpad.net/bugs/1631038>
[17:00] <voidspace> frobware: fs.max-files
[17:05] <frobware> voidspace: ty
[17:06] <frobware> voidspace: any particular value that will take me over 18 containers?
[17:06] <voidspace> frobware: I read the current value and then added a zero... :-)
[17:09] <frobware> voidspace: should this be: fs.file-max ?
[17:10] <voidspace> frobware: uhm, yes. Sorry. Dodgy memory.
[17:10] <frobware> voidspace: and what's the setting that requires a reboot?
[17:11] <rogpeppe1> alexisb: thanks for hitting $$merge$$ again for me! :)
[17:11] <rogpeppe1> alexisb: i filed another "sporadic test failure" bug...
[17:11] <alexisb> rogpeppe1, np, I will keeo an eye on it
[17:11] <alexisb> rogpeppe1, yeah we have a bug for that one
[17:12] <alexisb> but thank you
[17:12] <rogpeppe1> alexisb: it's just landed, yay!
[17:12] <alexisb> thank you rogpeppe1!
[17:12] <rick_h_> voidspace: do you have a link to the bug you created for tracking the packaging?
[17:12] <rogpeppe1> alexisb: ah, i didn't find the relevant bug, perhaps i should mark mine as dupe
[17:13] <alexisb> yeah when a have a moment, I wil go cross check with our list
[17:13] <voidspace> rick_h_: I'll do it now...
[17:13] <frobware> rick_h_: https://bugs.launchpad.net/juju-release-tools/+bug/1631038
[17:13] <mup> Bug #1631038: Need /etc/sysctl.d/10-juju.conf <juju-release-tools:Triaged> <https://launchpad.net/bugs/1631038>
[17:13] <frobware> voidspace: is that it?
[17:14] <rick_h_> voidspace: frobware ty
[17:14] <voidspace> frobware: plus sysctl -p
[17:14] <voidspace> frobware: and you need the max_user_instances set higher than the default 128 too
[17:14] <voidspace> frobware: but that *should* work (worked for me)
[17:14] <rogpeppe1> alexisb: p'raps we should have a standard format for the subject line of sporadic test failures
[17:14] <rogpeppe1> alexisb: my bug is here FWIW https://bugs.launchpad.net/juju/+bug/1632412
[17:14] <mup> Bug #1632412: apiserver: sporadic test failure in pingerSuite.TestAgentConnectionDelaysShutdownWithPing <juju:New> <https://launchpad.net/bugs/1632412>
[17:15] <frobware> rogpeppe1: can we not dot it with tags?
[17:15] <voidspace> rick_h_: https://bugs.launchpad.net/juju/+bug/1632414
[17:15] <mup> Bug #1632414: Package sysctl.conf file with juju <juju:New> <https://launchpad.net/bugs/1632414>
[17:15] <rogpeppe1> frobware: i guess so, although a standard form for the subject line would help too
[17:16] <rogpeppe1> frobware: tbh i didn't even know that bugs could have a set of tags
[17:17] <frobware> rogpeppe1: I add network often enough... :)
[17:17] <voidspace> rick_h_: there is morre we could do on bug 1602192
[17:17] <mup> Bug #1602192: when starting many LXD containers, they start failing to boot with "Too many open files" <lxd> <juju:In Progress by rharding> <lxd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1602192>
[17:17] <rogpeppe1> frobware: where do you see the tags in the bugs list?
[17:17] <rick_h_> voidspace: right, just want to get what we're doing for 2.0 to move it forward
[17:17] <voidspace> rick_h_: but should we mark is fix committed now we have the warning in and a separate bug for the system settings
[17:17] <rick_h_> voidspace: and we'll look at next steps from there
[17:17] <rogpeppe1> frobware: ah, i see on the lower right
[17:17] <rick_h_> voidspace: hmm, not sure I want to mark it fix-committed
[17:17] <voidspace> rick_h_: kk
[17:18] <frobware> rick_h_, voidspace: given that I've been asking for your additional settings can we update the bug to contain more than the two entries currenty listed?
[17:18] <rogpeppe1> frobware: there are enough "intermittent-failure" bugs that it's still hard to find the one that applies
[17:18] <rick_h_> frobware: voidspace please update the bug to have all the info needed so they can move that
[17:18] <rogpeppe1> frobware: i think the subject should at least mention the failing package and test.
[17:18] <frobware> rogpeppe1: rather like a (good) commit message... :)
[17:19] <rogpeppe1> frobware: exactly
[17:19] <rogpeppe1> frobware: anyway, now that you've brought it to my attention, i've added the intermittent-failure tag
[17:19] <rogpeppe1> frobware: thanks for that
[17:20] <frobware> rick_h_: I want to punt the completion of that to voidspace as I'm cargo-culting... but I think voidspace and jam have the absolute things to change...
[17:20] <rick_h_> frobware: k
[17:22] <frobware> rick_h_: happy to validate because ATM, conjure-up openstack localhost fails for me.
[17:24]  * frobware EOD
[17:28] <voidspace> macgreagoir: looking at #6424
[17:29] <voidspace> macgreagoir: actually, #6424 has existing review comments that need addressing
[17:30] <voidspace> macgreagoir: looking at 6393
[17:31] <voidspace> macgreagoir: I would go with rick_h_ for that PR :-)
[17:32] <voidspace> macgreagoir: that one LGTM
[17:32] <voidspace> rick_h_: there's a chance macgreagoir is EOD
[17:33] <voidspace> rick_h_: shall I set "Change the grant admmodel permission to add-model" to merge?
[17:33] <voidspace> rick_h_: https://github.com/juju/juju/pull/6393
[17:33] <rick_h_> voidspace: looking, did it get the fallback going?
[17:33] <voidspace> rick_h_: yep, there's a test for it too
[17:33] <rick_h_> voidspace: then yes please
[17:57] <dooferlad> voidspace / rick_h_: https://github.com/juju/juju/pull/6406 -- last change was a comment fix so it should be good to go.
[17:58] <voidspace> dooferlad: looking
[17:58] <voidspace> then EOD
[17:59] <rick_h_> voidspace: ty
[17:59] <rick_h_> dooferlad: ty as well
[17:59] <dooferlad> voidspace: thanks. EOD + 1h for me. This is back after the toddler has been put to bed for a last minute code poke.
[18:00] <voidspace> rick_h_: you got there before I could review it
[18:00] <voidspace> g'night all
[18:02] <stokachu> frobware: whats the conjure-up failure from?
[18:02] <stokachu> ive run it on yakkety and the charms fail because of ipv6 i think
[18:03] <rick_h_> stokachu: is the ipv6 issue noted? I thought we had the ipv6 issues licked where you'd get an ipv6 default address?
[18:03] <stokachu> rick_h_: so with a fresh yakkety and juju rc3 a default deploy assigns ipv6 to applications
[18:06] <stokachu> rick_h_: i think juju does right by giving it ipv6 but the charms fail?
[18:06] <stokachu> haven't had a chance to dig further into it
[18:10] <rick_h_> stokachu: so ipv4 should be preferred, but if it has ipv6 then I guess that's ok except juju doesn't support ipv6 yet
[18:11] <stokachu> rick_h_: i can boot another yakkety system here and run it again
[18:11] <stokachu> rick_h_: will juju status show ipv6 even if it uses ipv4?
[18:12] <rick_h_> stokachu: so it should pick ipv4 if it's there as the preferred and not show ipv6. It shouldn't show ipv6 if it's using v4
[18:12]  * rick_h_ is trying to find the bug/pr we fixed along those lines recently
[18:12] <stokachu> rick_h_: ok
[18:12] <stokachu> rick_h_: also would that be in rc3
[18:14] <rick_h_> stokachu: https://bugs.launchpad.net/juju/+bug/1624495 yes, would be in there.
[18:14] <mup> Bug #1624495: operations fails on rackspace because of ipv6 address in dns-name <rackspace> <status> <juju:Fix Committed by mfoord> <juju-ci-tools:Won't Fix> <https://launchpad.net/bugs/1624495>
[18:14] <stokachu> rick_h_: ohhh
[18:14] <stokachu> so i should setup xenial to configure both ipv4 and ipv6 with lxd init
[18:14] <stokachu> so ill do that in another test in addition to a default yakkety run
[18:15] <rick_h_> stokachu: maybe? I don't want to have issues with juju 2.0 not working with conjure-up I guess
[18:15] <rick_h_> stokachu: that's why I ask if you've filed a bug or something or what's up here. That's news to me that it's not working for you.
[18:15] <rick_h_> stokachu: and we're in lock down for GA at EOD today so kind of :/
[18:15] <stokachu> rick_h_: i just ran it this morning
[18:15] <rick_h_> stokachu: ah ok
[18:16] <rick_h_> stokachu: yea, please let me know if there was any ipv4 or if it was pure ipv6 and what versions of the stack we're looking at there. lxd tests on yakkety pass CI so curious if things aren't there for you as there's no father bug fixes in that area on the plate for tomorrow's freeze
[18:17] <stokachu> rick_h_: ok im testing right now for yakkety and xenial
[18:17] <rick_h_> stokachu: ty
[18:17] <stokachu> rick_h_: normally on xenial i dont choose to configure ipv6
[18:17] <stokachu> ill enable it though and see what happens
[18:17] <rick_h_> stokachu: ah ok, so it's working sans ipv6 then?
[18:18] <stokachu> yea that works
[18:18] <rick_h_> stokachu: ah ok, I feel better then
[18:18] <stokachu> but yakkety may be different i want to verify
[18:18] <rick_h_> stokachu: and it should work ok with ipv6 and ipv4 enabled, but pure v6 won't work
[18:18] <rick_h_> stokachu: k, ty
[19:43] <natefinch> sinzui: I'm not really sure what the correct behavior for this bug is: https://bugs.launchpad.net/juju/+bug/1613858
[19:43] <mup> Bug #1613858: generate-tools ignores 2.x agents and creates bad path <jujuqa> <metadata> <regression> <rteam> <simplestreams> <streams> <juju:In Progress by natefinch> <https://launchpad.net/bugs/1613858>
[19:45] <sinzui> natefinch: we have a lot of Wiggle room. the goal is to allow a private cloud to assemple strreams to boostrap with. 1. stop ignoring agents with major version greater than 1, then make a sensible dir structure as I show 1.x generates
[19:46] <natefinch> sinzui: I don't know what you mean when you say the tool ignores them.  as I said, I don't know what the intended behavior is
[19:47] <sinzui> natefinch:  with juju 1, run "juju metadata generate-tools -d mystreams --stream devel". it makes streams with the agents in the dir. it also makes the correct dir tree.
[19:47] <sinzui> natefinch: doing that with juju 2, it should also recognise the 1x and 2x agents.
[19:48] <natefinch> sinzui: I don't know what the correct directory tree should look like.  Is it just a v2 where we have a v1 now?
[19:48] <sinzui> natefinch: I think juju 1x should also recognise 2.x agents, but that is not the critical path to enbling a provate cloud
[19:48] <sinzui> natefinch: The rules have not changed in 3 years!
[19:49] <sinzui> natefinch: 2,x's output sould match 1x's output
[19:49] <sinzui> natefinch: both jujus should include 2.x agents, but for today, we just need to get 2.x to make streams
[19:50] <natefinch> sinzui: I really don't know how to say in any other ways that I don't know what the expected output should be.  When I run juju emtadata-tools, I get this: http://pastebin.ubuntu.com/23309748/
[19:50] <natefinch> sinzui: what part of that is wrong, and what should it look like instead?
[19:51] <natefinch> sinzui: assume I have no clue what streams stuff is supposed to look like... because I don't.
[19:53] <sinzui> natefinch: that is why I keep suggesting to run with 1.x we used juju  1.15.0 to 1.25.2 to make streams with that command. the output works for juju. Juju 2 needs to make the same tree. Juju 1 and 2 need to bootstrap with that tree
[19:53] <natefinch> ok
[19:53] <sinzui> natefinch: that paste lookss right, BTW, except there are not agents shown in devel.
[19:54] <natefinch> sinzui: I didn't have anything to put there, so I figured I'd just run it to see what it generates without anything
[19:54] <sinzui> :), I would ahve done the same
[20:16] <menn0> stupid irc client, not reconnecting lately
[20:16] <menn0> thumper: so are we still able to land things?
[20:16]  * thumper shrugs
[20:16] <thumper> what thing?
[20:16] <menn0> thumper: for the release? no branch cut yet as far as I can tell.
[20:17] <thumper> menn0: what is the mongo update syntax for updating values inside a slice?
[20:17] <thumper> alexisb: when are we freezing landings?
[20:17] <thumper> menn0: and what are you wanting to land?
[20:17] <thumper> if it is just a bug fix, I'd say that'd be fine
[20:17] <menn0> thumper: a specific element in an array you mean?
[20:17] <thumper> but we want to reduce churn on change
[20:18] <thumper> menn0: relations, there is a slice of structures called "endpoints", inside those values is "service-id"
[20:18] <thumper> I want to remove that one and add "application-id"
[20:18] <alexisb> thumper, not until eod
[20:18] <alexisb> for US
[20:18] <menn0> thumper: the fix for this: https://bugs.launchpad.net/juju/+bug/1629194
[20:18] <mup> Bug #1629194: Don't warn for default architecture on bootstrap <juju:In Progress by menno.smits> <https://launchpad.net/bugs/1629194>
[20:18] <menn0> thumper: https://github.com/juju/juju/pull/6425
[20:19] <menn0> thumper: actually, I'd appreciate your thoughts on the direction wallyworld and I took with this. See the example output in the PR description.
[20:20]  * rick_h_ goes to get the boy from school
[20:20] <alexisb> hml, ping
[20:21] <hml> alexisb: pong
[20:21] <alexisb> heya hml, happy tuesday :)
[20:21] <alexisb> just checking in on how things are going
[20:22] <thumper> menn0: looks good to me
[20:22] <hml> alexib: going okay - i have the pr for the api version stuff out - resolved the git issues - hope to have the other code available tonight - but still no interwebs at home.
[20:22] <menn0> thumper: one reservation I had is that we went with a syntax that's almost the same as the constraints format but is missing "arch=" for the architecture
[20:23] <menn0> thumper: regarding your mongodb question, you can't do it in one operation
[20:23] <menn0> thumper: http://stackoverflow.com/questions/4669178/how-to-update-multiple-array-elements-in-mongodb
[20:23] <alexisb> ok hml do you need a review for the api version stuff?
[20:23] <menn0> thumper: either update them one at a time, or replace the entire field/doc
[20:24] <thumper> I know how many values there are
[20:24] <thumper> I can explicitly identify them
[20:24] <thumper> ah...
[20:24] <menn0> thumper: well there is this to address a particular field: https://docs.mongodb.com/manual/reference/operator/update/position/#up._S_position
[20:24] <hml> alexisb: axw did an initial review for the goose piece, i resolved his comment.  both PRs need review - details in email sent recently
[20:24] <thumper> so...
[20:24] <thumper> endpoint.0.service-id
[20:24] <menn0> thumper: but that doesn't exist in 2.4
[20:24] <alexisb> hml, ack
[20:25] <menn0> thumper: actually ignore $position, not what you want anyway
[20:25] <alexisb> aah hml I see the PR from an hour ago now, awesome!
[20:25] <menn0> thumper: I would read out the field as a bson.D, update it in memory and then replace it
[20:29] <redir> another PR https://github.com/juju/juju/pull/6429 pretty similar to https://github.com/juju/juju/pull/6399 which bring htem up to speed with https://goo.gl/yqrrPI
[20:29] <redir> PTAL
[20:34] <perrito666> redir: looking
[20:34] <redir> perrito666: gracias
[20:40] <perrito666> redir: you do not fool around when it comes to QA steps
[20:42] <alexisb> redir, sorry I am stuck in a call
[20:42] <redir> alexisb: np.
[20:43] <redir> perrito666: :) Since there's 3 commands getting collapsed into one I wanted to make sure they actually work:|
[20:43]  * katco falls back to a different computer
[20:49] <alexisb> wallyworld, when you are online can you please take a look at this bug: https://bugs.launchpad.net/juju/+bug/1631529
[20:49] <mup> Bug #1631529: "upload-tools strikes back" cannot upgrade with streams <jujuqa> <simplestreams> <upgrade-juju> <juju:Triaged by alexis-bruemmer> <https://launchpad.net/bugs/1631529>
[20:52] <perrito666> redir: just being curious here, what is a not valid utf-8 string?
[20:52] <redir> perrito666: preexisting code
[20:53] <perrito666> redir: I am curious because I thought any thing was a valid utf string :p
[20:55] <redir> perrito666: not so or there wouldn't be a need for the replacement character
[20:55] <redir> �
[20:57] <perrito666> redir: reviewed
[20:57] <perrito666> redir: as I understand, there might not be a symbol but utf pretty much has a place for everything
[20:58] <redir> perrito666: my best WAG is it is supposed to validate that one hasn't input non printables in the command line ^I etc..
[20:58] <perrito666> redir: its possible, it was just a curiosity
[20:58] <redir> perrito666: https://blog.golang.org/strings
[20:58] <redir> perrito666: indeed
[21:00] <perrito666> redir: well I had only a few comments
[21:00] <perrito666> redir: great work
[21:01] <redir> perrito666: you look at this too? https://github.com/juju/juju/pull/6399
[21:01] <redir> same basic concept, different snowflake
[21:02] <perrito666> redir: sure, have a call with alexisb now but ill read it after
[21:02] <redir> k
[21:03] <redir> perrito666: mg (spanish for ta?)
[21:05] <perrito666> redir: mg?
[21:06] <redir> perrito666: muchas gracias
[21:06] <wallyworld> alexisb: updated bug - i claim it is invalid. juju is working as designed
[21:06] <redir> wallyworld: I claim that all the time
[21:08] <alexisb> wallyworld, thanks
[21:08] <alexisb> wallyworld, hml also has some PRs up
[21:18] <menn0> rick_h_: ping?
[21:18] <rick_h_> menn0: pong
[21:18] <menn0> rick_h_: i was about to merge this but wanted to run it past you: https://github.com/juju/juju/pull/6425
[21:19] <menn0> rick_h_: see the output in the PR description
[21:19] <menn0> rick_h_: I decided to go with the same format as the constraints syntax for consistency
[21:20] <rick_h_> menn0: looking
[21:21] <menn0> rick_h_: adding MAAS output for completeness
[21:21] <rick_h_> menn0: cool LGTM
[21:22] <menn0> rick_h_: ok thanks
[21:23] <rick_h_> katco: ping, can you join the other #juju channel please to help out someone?
[21:23] <katco> rick_h_: sure
[21:23] <rick_h_> katco: they're asking if the lxd provider asks for zfs and I'm unsure of that behavior and have to run to take the boy to soccer atm
[21:23] <rick_h_> katco: ty
[21:42] <mup> Bug #1632477 opened: panic when deploying bundle when bundle relative path and bundle has relative paths and series is missing for an application <juju-core:New> <https://launchpad.net/bugs/1632477>
[21:42] <mup> Bug #1632483 opened: juju says error: No selected controller. when there is a typo in the -m parameter it should say "could not find specified model" <juju-core:New> <https://launchpad.net/bugs/1632483>
[21:46] <rick_h_> natefinch: ping
[21:48] <mup> Bug #1632477 changed: panic when deploying bundle when bundle relative path and bundle has relative paths and series is missing for an application <juju-core:New> <https://launchpad.net/bugs/1632477>
[21:48] <mup> Bug #1632483 changed: juju says error: No selected controller. when there is a typo in the -m parameter it should say "could not find specified model" <juju-core:New> <https://launchpad.net/bugs/1632483>
[21:51] <mup> Bug #1632477 opened: panic when deploying bundle when bundle relative path and bundle has relative paths and series is missing for an application <juju-core:New> <https://launchpad.net/bugs/1632477>
[21:51] <mup> Bug #1632483 opened: juju says error: No selected controller. when there is a typo in the -m parameter it should say "could not find specified model" <juju-core:New> <https://launchpad.net/bugs/1632483>
[21:54] <katco> rogpeppe1: i don't suppose you're still on?
[22:05] <rick_h_> wallyworld: can you forward me the email from natefinch  please?
[22:06] <wallyworld> sure
[22:06] <rick_h_> ty
[22:21] <mup> Bug #1632477 changed: panic when deploying bundle when bundle relative path and bundle has relative paths and series is missing for an application <juju-core:New> <https://launchpad.net/bugs/1632477>
[22:30]  * alexisb goes to pick up kid, biab
[23:17] <alexisb> veebers, ping
[23:23] <veebers> alexisb: hey o/
[23:23] <alexisb> veebers, you joininh us?
[23:24] <veebers> alexisb: sorry not today (unless it's really urgent) this standup time is a little awkward for me on Mon,Tues and Fri due to existing commitments