[00:16] wallyworld_: ack, lemmie get something to eat [00:16] ok, no rush [00:18] thumper: which pocket is Juju going to ship in 14.04 ? [00:18] thumper: was there any resoltuion on that discussion in SF that juju core developers should be using P [00:20] davecheney: well, there was the plan that the devs came up with, but that was overruled [00:21] davecheney: I hear that we will be in main with a dependency on juju-db not mongodb-server [00:22] thumper: so, devs will not be fixed to a certain series ? [00:22] thumper: wrt juju-core in main [00:22] if we need to use gccgo to compile for arm (for example) that would also need to be in main ? [00:28] * thumper shrugs [00:28] probably [00:34] wallyworld_: https://plus.google.com/hangouts/_/72cpi4lte1uucmppj5b94beve4?hl=en [00:40] thumper: right, thanks for confirming === bjf[afk] is now known as bjf [01:05] hey thumper, was the 14.04 planning/schedule doc finalised and sent out? I can't find it on drive [01:07] probably not :-) [01:08] axw: hangout? [01:08] okey dokey [01:08] thumper: sure [01:09] axw: https://plus.google.com/hangouts/_/72cpi4lte1uucmppj5b94beve4?hl=en [01:42] wallyworld_: for this machine call to the api to give supported containers, we should also report ip addresses [01:42] just a FYI [02:02] ok [02:26] thumper: I need to talk to you (or someone in core) about expectations around vlans in maas [02:26] hmm [02:26] how soon? [02:26] I'm going to have to run children to sports very shortly [02:30] thumper: can do it tomorrow [02:30] just wanted to register this in your head [02:35] ack [02:35] kids rescued by wife [02:35] but I've had a day of calls already [02:35] and would like to do some work [02:40] bloody hell [02:40] http://paste.ubuntu.com/6374105/ [02:41] ^ what happened here [02:41] the provisioner isn't starting machine 1 [02:41] thumper: calls != work. ACK :) [02:42] bigjools: if I wanted work calls I'd go back to engineering manager [02:42] axw: http://paste.ubuntu.com/6374105/ [02:42] any idea what happened ehre ? [02:42] looking [02:42] machine 1 is not goundf [02:42] because I just deployed the first service [02:44] sorry, no idea davecheney [02:45] davecheney: what's going wrong exactly? [02:46] juju deploy [02:46] machine never comes up [02:46] also, 2013-11-07 02:45:15 INFO juju password.go:94 setting password for "unit-gccgo1-0" [02:46] 2013-11-07 02:45:16 INFO juju password.go:94 setting password for "unit-gccgo1-0" [02:46] ^ why does it set the password twice ? [02:47] I haven't looked at most of the provisioner code I'm afraid [02:48] fair enough [02:49] (not) awesome [02:49] restarting the provisioner picked up the missing machine [02:49] and provisioned it [02:49] yay timing issues ! [02:50] I'm guessing the machine status isn't added in the same transaction [02:52] my god the agents query tools a lot [02:52] https://bugs.launchpad.net/juju-core/+bug/1248800 [02:52] <_mup_> Bug #1248800: worker/provisioner missed signal to start new machine [02:55] davecheney, surely you can take a guess at the importance. I think we want to commit to fix that bug in the next 6 months....High [02:55] davecheney, I think we have a bug already about the redundant queries [02:57] sinzui: i was told not to triage bugs anymore [02:57] well, not to screw with their priority [02:57] oh lovely. I get to guess at all the importances [03:10] axw: with the api design and errors, here's another example that uses the pattern - apiserver/provisioner/provisioner.go func (p *ProvisionerAPI) Status() . In this case, the Status() method can return an error preparing to execute the bulk operations, but the bulk calls themselves do not return an error, but instead record it in the result object [03:11] wallyworld_: hmm yeah fair enough. it allows you to distinguish an error relating to the individual calls from initial setup [03:11] yeah [03:12] just throws me a little, because if I see no error returned, I expect that everything is fine [03:12] i can understand that [03:13] i depends how the api defines "fine" [03:13] true :) [03:33] wallyworld_: is it intentional that you can't delete environ-config attrs from state? (I guess not, but before I go changing it...) [03:33] SetEnvironConfig updates keys that are there, but never deletes things you remove from the config [03:34] axw: i'm not sure tbh [03:34] ok. I'll create a bug and let someone shoot it down if needed [03:35] axw: be warned, the config stuff has been a source of way too much bikshedding [03:35] ok :) [03:35] the scars run deep from what i've been told [03:35] wallyworld_: I wouldn't care, but it actually is preventing me from testing something [03:36] william is probably the best person to ask [03:36] thanks, I'll run it by him later [03:40] fwereade: when you're awake, please take a look at https://bugs.launchpad.net/juju-core/+bug/1248809 [03:40] <_mup_> Bug #1248809: state.State.SetEnvironConfig never forgets [03:40] wallyworld_: oh yes [03:40] lets not start a second land war in asia [04:05] * thumper going to make dinner, back later tonight for the meeting === thumper is now known as thumper-afk === wedgwood is now known as Guest32887 [07:05] axw, got to go out to the bank -- but, yes, SetEnvironConfig hardly works at all [07:05] axw, saying it was "designed" is very charitable [07:09] fwereade: hah :) [07:09] ok [07:09] I saw in a comment to dimitern a bug regarding passing old/new to SetEnvironConfig [07:09] probably they could be tackled at the same time [07:10] fwereade: however... the new EnvironmentSet API call assumes a config subset [07:11] so, either that would need to change, or a new API would be needed for deleting, or the current behaviour remains [07:11] anyway, ttyl [07:19] jam: I implemented an alternative to PushEnvironmentSecrets: https://codereview.appspot.com/22720043/ [07:19] does the same as what we do now, under the assumption the code is going to be deleted [07:21] axw: where are you calling updateSecrets? In NewAPIConn ? [07:22] yup [07:22] axw: lgtm [07:23] cool. the other way would make sense if it were to stick around, but I don't think we'll need it at all [07:23] we should be able to start the agent up with full environment config initially with synchronous bootstrap [07:54] sinzui: when you start I've pushed juju-core 1.16.3 to trusty and all of the backport packages have built in the packaging PPA's [08:07] mornin' all [08:16] rogpeppe: morning [08:16] TheMue: hiya [09:01] fwereade: when you're back- since you started reviewing the other one, could you take a look here before I land: https://codereview.appspot.com/22720043/ [09:01] * fwereade is backand looking at axw's branch [09:01] ta === jtv1 is now known as jtv [09:43] sorry rogpeppe, I meant to ask about that comment - already merged [09:43] will delete it when I touch the file next [09:43] axw: np [09:54] jam: I don't know the upstart config off hand, but env vars were being pushed thru there before for provider type, and I think LXC bridge type [09:55] we moved *away* from setting env vars to simplify upgrading === thumper-afk is now known as thumper [10:02] jam, mgz: meeting time [10:03] fwereade: meeting [10:03] fwereade: meeting? [10:04] mgz: meeting? [10:48] night all [11:15] Guys, is it 'juju sync-tools --source=. --debug' to sync locally from tools/releases ? [11:27] Because neither --source=. or --source=tools/releases/ is working here. === _mup__ is now known as _mup_ === BradCrittenden is now known as bac [12:45] fwereade: i've just updated https://bugs.launchpad.net/juju-core/+bug/1246343 [12:45] <_mup_> Bug #1246343: destroy-environment no longer removes .jenv

[13:56] jam: wow, 34810 running goroutines; that's quite something. [13:56] rogpeppe: well the go claims that there you can cheaply spawn 100,000s of them, right? :) [13:56] jam: indeed - it's just more than i expected [13:57] rogpeppe: yeah, with 7k agents that means almost 5 per agent [14:02] jam: you might be interested in this - it's a characterisation of all the stack traces by set of called functions; the count is the number of goroutines with that stack trace: http://paste.ubuntu.com/6376480/ === Guest32887 is now known as wedgwood [14:04] jam: looks like everything's blocked on mongo [14:06] rogpeppe: could be, though mongo itself was at 0% cpu during this time [14:21] jam: goroutine 216906 seems to be the one with the lock (the write lock at any rate) [14:27] sinzui: after standup, can you look at https://code.launchpad.net/~jcsackett/charmworld/multiple-appflowers/+merge/194241 for me? [14:27] jam: wonder if it would be useful to instrument mgo with some stats (github.com/GaryBoone/GoStats might provide an easy way to get some more useful stats without making enormous log files) [14:32] jam: actually i may have been thinking of github.com/rcrowley/go-metrics [15:46] natefinch: ping [15:47] rogpeppe: yo [15:48] natefinch: i've been trying to think through the failover stuff, and hit a tricky issue [15:48] natefinch: i wondered if you wouldn't mind a chat about it to try to get my thoughts straight [15:49] natefinch: np if inconvenient [15:49] rogpeppe: sure thing [15:50] natefinch: usual hangout? [15:50] sure [15:50] https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig?authuser=1 [16:10] fwereade: any chance you could join us? [16:20] hey sinzui, is bug #1238934 something we can backport to saucy/precise? [16:20] <_mup_> Bug #1238934: manual provider doesn't install mongo from the cloud archive

[16:20] or should we just have it in 1.18 as a whole and tell people to use the PPA for manual provisioning? [16:22] sigh [16:23] jcastro, we can, but we can do one release a week. so if it do, we delay 17 and 18 [16:23] sorry I didn't mean to depress you! [16:23] I would like 17 next week and 18 the following week [16:23] are there plans to bring 18 to precise/saucy? [16:24] jcastro, all stable releases go to all supported series [16:24] oh ok [16:24] We always do that [16:24] so waiting 2 weeks is the smart thing to do [16:24] 1.16.3 will be in the archives in a few hours BTW [16:24] ok I wasn't aware of the backport treadmill -- that works out for me! [16:25] jcastro, I hope that with more automation, we can entertain a stable and devel release in the same week [16:26] yeah I'm just trying to sync the manual provisioning docs with 1.18, but I have two weeks to figure that out, heh [17:12] interesting: http://www.packer.io/intro [19:01] rogpeppe: I saw that packer thing. Kinda neat, but not sure the real-world utility. Sure you can take a machine and make an image for EC2 or virtualbox or whatever. You still have to make the original correctly, though, and that seems like the more interesting challenge (and the one we're tackling). [19:02] natefinch: yeah, i haven't read it properly - just thought it looked interesting [19:04] rogpeppe: yep [19:24] natefinch: trying to work out what's going on with jam's enormous stack trace, i quickly hacked up this: http://paste.ubuntu.com/6377995/ [19:24] natefinch: it analyses a stack trace and produces an SVG call graph summary [19:25] natefinch: if you get his stack trace with: curl http://ubuntuone.com/6vKrM07H7BTHUa9Xqvy16V | ungz > /tmp/stacktrace [19:25] rogpeppe: damn, roger. Quickly hacked up.... I hope we're paying you enough :) [19:26] natefinch: and then run the above program on it: go run stacktrace.go < /tmp/stacktrace > /tmp/x.svg [19:26] natefinch: and open your browser on file:///tmp/x.svg [19:26] natefinch: i stole all the interesting bits from the pprof perl script [19:26] natefinch: (first time i've ever translated perl to Go!) [19:27] natefinch: (first time i've ever read any perl actually :-]) [19:27] * natefinch shudders [19:27] natefinch: it's not too bad in that particular case [19:28] ha! [19:28] natefinch: i've got the arrows all backwards! [19:28] heh [19:31] rogpeppe: tar -xz is saying it's not in gzip format [19:31] natefinch: sorry, i said ungz; i meant unxz [19:31] natefinch: it's not a tar file [19:32] rogpeppe: ahh right, because it's just one file. Stupid linux and it's stupid 10 different ways to pack files :/ [19:32] natefinch: this version puts the arrows in the right direction: http://paste.ubuntu.com/6378028/ [19:32] back in my day we only had .zip and we liked it :/ [19:33] natefinch: back in my day we only have .Z and we liked it :-) [19:33] s/have/had/ [19:33] * thumper is going to be taking daughter to the dentist, so not really around until later [19:41] rogpeppe: took me a while, but I got there. Pretty cool [19:41] natefinch: cool [20:01] right, that's me done and dusted [20:02] natefinch: g'night [20:02] rogpeppe: g'night [20:27] natefinch, do you have time to build a win installer for 1.16.3 and request a signing? [20:28] sinzui: sure [20:29] thank natefinch [20:29] ^ yoy [20:29] ^ you [20:30] I give up. My head hurts, I two ways of packing perfect packages, yet neither method is perfect in itself [20:30] * sinzui ponders the consequences to drinking and retrieving children from school [20:36] sinzui: I think it's funny we're releasing a new windows client that includes a fix for the local provider.... that can't run on windows anyway :) [20:37] ha ha [20:37] I know [20:37] natefinch, I am happy for you to say no, it is just busy work [20:38] sinzui: it's super quick, no problem. Just amusing is all. [20:39] we did an ubuntu release for 1.14.1 that had no changes for ubuntu. It was just to acknowledge that windows got a different version [21:24] sorry juju-gui, you got spam from me [21:24] you don't want to use my devel packages [21:26] * thumper goes to hack on kvm stuff [21:26] and will effectively disconnect === thumper is now known as thumper-hacking === gary_poster is now known as gary_poster|away [22:36] thumper-hacking: yay for my lxc environment being back to being useful. Tested the updated gui with bundle super powers in it and so much nicer/faster than ec2 === thumper-hacking is now known as thumper-gym