[00:30] thumper: can I do a 1:1 with you today ? [00:31] 'cos it was actual queens birthday yesterday === kadams54 is now known as kadams54-away === natefinch-afk is now known as natefinch [01:29] * natefinch wonders if it's worth the effort to propose something he thinks is better, but different. [01:31] natefinch: isn't that like the best thing you can propose? [01:32] perrito666: people don't like different, even if it's better [01:32] perrito666: which means I have to fight for it. [01:32] natefinch: are yo aksing us to tell you it is ok to be lazy? :p [01:32] davecheney: yep [01:33] perrito666: nah [01:34] natefinch: too bad I was about to tell you it is ok to be lazy :p [01:38] perrito666: heh. Nah, I'm the type of person that always tries the hard way first. [01:41] perrito666: I had an epiphany tonight - I realized our charms are actually plugins for juju that we ask other people to write. And looking at them from that lens... our plugin architecture is pretty terrible. [01:42] which is why we hide it with charm helpers and gocharm and the like. [01:53] natefinch: ook [01:54] natefinch: It would seem to me you are hitting the wrong plants :p [01:55] * perrito666 wonders if his battery will run out before the tests finish the run [02:00] anyway, I'm working on the spec for workload process plugins (i.e. plugins to run docker or rocket or whatever containers etc).... and trying not to make the same mistakes. At some point I'd love to propose a "new-style charm" architecture. But for now I'm just wondering if I can get these new plugins to not follow in the footsteps of the old ones. [02:08] wallyworld: would you mind reviewing https://github.com/juju/juju/pull/2524 please? 1.22 and 1.24 differ a little bit [02:13] sure [02:23] axw: looks good. the block device stuff only came in 1.23 right? [02:26] wallyworld: it seems it was in there in 1.22, but in a different form [02:26] wallyworld: one which didn't have the issue I fixed in 1.24 [02:27] ok, so this fix isn't relevant [02:27] right [02:27] great [02:30] wallyworld: I'm just going to rename that card to "port to 1.22 and master" [02:30] ok [02:30] not really worth adding another card right? [02:30] nah [02:54] waigani: how goes the hunt on bug 1463117 ? [02:54] Bug #1463117: Juju 1.24-beta6.1 unit commands hang indefinitely

[02:55] thumper: it came in on this commit: f35a8c6c2d2ca2 [02:56] waigani: when is that commit? [02:56] thumper: so the commands in the debug-hook context are expecting stdin from the cmd context [02:56] waigani: and what was the branch fixing / adding? [02:57] thumper: but that branch changes how it works [02:57] ahh... I remember that branch [02:57] * thumper looks at axw [02:57] luckily axw did the debug-hooks originally too :) [02:58] thumper: it also brought in a new juju/utils dependency, this is the log for that: [02:58] exec: don't use stdin to send commands to shell [02:58] [02:58] Using stdin to send commands to the shell means that commands run with this cannot use stdin, or they will consume subsequent script input [02:58] * thumper nods [02:58] thumper: but I don't think the bug is in the dep [02:59] by fixing the jujuc commands to support stdin, we broke debug hooks... [02:59] *sad face* [02:59] thumper: in summary, yes [03:00] thumper: I'm poking around cmd/jujud/main.go where we read from stdin and pass it in with the jujuc.Request [03:02] thumper: if we don't read from stdin and pass it in with the req, and instead set up the cmd.Context.Stdin with a nil bytes.Buffer pointer on the jujuc Server - it works [03:03] um... ok... I don't understand all those bits very well [03:03] waigani: best thing would be to run a solution past axw [03:04] however my gut says "here be dragons" [03:04] I feel that any change may have repercussions in other unintended areas [03:05] however, saying that... [03:05] if we are able to test: [03:05] jujuc command simply [03:05] jujuc command piping stdin [03:05] juju run [03:05] hooks in scripts [03:05] and debug hooks [03:05] if they all work, [03:05] then it seems like we have probably got things in good order [03:07] thumper: right, also the solution can't break the bug the original commit fixed. [03:08] thumper: which was this guy 1454678 [03:08] waigani: that was 'jujuc command piping stdin' IIRC [03:08] #1454678 [03:08] Bug #1454678: "relation-set --file -" doesn't seem to work

[03:08] thumper: yep [03:10] axw: ping? [03:29] waigani: pong. sorry, was making lunch [03:31] axw: hey, I think commit f35a8c6 broke debug hooks [03:32] f35a8c6 made jujuc support stdin [03:33] waigani: oh, what's it doing? eating atm, I'll have a look after [03:34] axw: I think where we read out the bytes buffer of stdin leaves the cmd.Context stdin empty and the commands in the debug hook context are expecting it [03:35] axw: I'm currently poking to back up that theory [03:35] axw: so I'll step back and give you the context [03:35] axw: I'm looking at this bug #1463117 [03:35] Bug #1463117: Juju 1.24-beta6.1 unit commands hang indefinitely

[03:37] If I comment out the lines where we read from cmd.Context.Stdin (around cmd/jujud/main.go:86) and don't set Stdin in the jujuc.Request, the bug is gone [03:37] i.e. I can debug a hook, call config-get and it returns instantly [03:38] if I leave the change in, the call hangs indefinitely [03:40] waigani: odd, it should just get EOF? [03:42] hm no, it's going to read from the terminal [03:43] axw: could we use something like peek to read from Stdin without emptying he buffer? [03:44] waigani: no, I think we need to do it differently: pass the FD to the server process [03:44] going to get messy [03:45] that was thumper's concern [03:45] waigani: it might be safer to back it out and reopen the bug, defer to 1.25 [03:46] axw: yeah? [03:46] wallyworld: ^^ that change to support passing config via stdin is causing problems [03:46] oh bother [03:47] um [03:47] sounds like breaking debug hooks is worse than relation set --file not working [03:48] we would look to fix in a 1.24.1 though [03:48] there's potentially other work queued up for 1.24.1 also [03:48] sounds fine [03:49] I just don't think it's worth blocking 1.24 [03:49] at this stage, we need to get the release out yes [03:50] and the relation-set one seems like the lesser of 2 evils [03:50] unless i'm missing something [03:51] wallyworld: yep, that's my take [03:52] axw: would one need to back out the utils change too? [03:52] waigani: do you want to do that, or shall I take it off your hands? [03:52] wallyworld: I don't think that's necessary [03:52] yeah, that's what i was thinking [03:52] * axw looks [03:52] or hoping [03:52] wallyworld: I've tested just the utils and it does not cause the bug to happen [03:53] waigani: awesome. ty [03:54] axw: why would "peeking" at stdin not work? [03:54] axw: It fixed the bug in my testing [03:55] waigani: can you explain what you mean by that? [03:55] waigani: I mean, in terms of how you would do it. what change did you make in testing? [03:56] waigani: data may come into stdin at any time, you can't peek at what's not there yet [03:56] waigani: until the file is closed, whatever's reading from it will block until there's data [03:57] I mean, block until there's data or it's closed [04:04] axw: right, what I did was a hack using mock data - not a real solution. But it did show the problem was reading from stdin left it empty. Is there a way of resetting cmd.Context.Stdin to os.Stdin and pre-populate it with the command we just read off? [04:06] waigani: the problem is not that we've read data off stdin and then something else wants it and can't get it. the problem is that there was no stdin data to start with, and the ioutil.ReadAll in cmd/jujud/main.go is waiting for it (forever) [04:07] waigani: it's not a problem when the jujuc commands are run by agents, because they don't have a terminal. but when you use debug-hooks, you're running the hooks from inside a terminal. [04:07] axw: ah, got it [04:10] thumper: I think the LTS animal should be Xuanhuasauru [04:10] because everyone will think it's spelt Xanthusela [04:10] axw: so your idea was to pass through the file descriptor so the alias command can be executed directly from the terminal? [04:11] waigani: that's one option, though I'm not sure how that'll work on Windows. it might be simpler to ditch net/rpc for juju/rpc, so we can have the server request data from stdin on demand [04:12] waigani: anyway, I don't think we should do that yet [04:12] axw: yep, not a quick fix. I'll update the bug report, back out that commit and reopen the bug it fixed. [04:12] waigani: thank you [04:15] davecheney: http://www.teamnameshirts.com/teamshirts.php?name=XUANHUASAURUS [04:18] % go test -race -timeout=600m ./state [04:18] smoke me a kipper [04:19] waigani: nailed it [04:36] axw: can i edit the resources spec so i can add a link to the new delivery schedule doc? [04:36] axw: http://reviews.vapour.ws/r/1895/ [04:36] wallyworld: sure, just a moment [04:36] ta [04:37] wallyworld: you have edit rights now [04:37] ty [04:37] thumper: % go test -race -timeout=600m ./state [04:37] ok github.com/juju/juju/state 808.283s [04:37] \o/ [04:37] heh... 600m [04:38] waigani: thanks, LGTM [04:38] axw: cheers [04:47] wallyworld: I'm going to have to do the lifecycle card before the persistent volume deletion one. we don't currently trigger lifecycle changes in all hte necessary places [04:47] ok [04:47] do we need to do for 1.24? [04:48] wallyworld: doesn't have to be done for 1.24 [04:48] even better [05:13] Bug #1454678 opened: "relation-set --file -" doesn't seem to work

[05:14] davechen1y: with go, is it safe to delete entries from a map while iterating through it? [05:14] my gut says no [05:14] but perhaps go is "special" [05:15] thumper: your gut is correct [05:15] kk, ta [05:15] let me look up the specifics [05:16] The iteration order over maps is not specified and is not guaranteed to be the same from one iteration to the next. If map entries that have not yet been reached are removed during iteration, the corresponding iteration values will not be produced. If map entries are created during iteration, that entry may be produced during the iteration or may be skipped. The choice may vary for each entry created and from one iteration to the next. If [05:16] hmm [05:16] i guess that is less pesimistic than I suggested [05:17] it certainly won't cause an infinite loop [05:21] thumper: some good news, the reflection crash on ppc64 that I reported last month is fixed [05:21] so I'll roll back the workaround this arvo === brandon is now known as web [05:28] w00t [05:28] davechen1y: I guess I was wanting confirmation that removing elements from a map won't cause elements that should be iterated over to be skipped due to some underlying structure rebalance === Spads_ is now known as Spads [08:32] voidspace, hey there [08:34] dimitern: hi [08:34] voidspace, I've confirmed that lxc-stop does not trigger a DHCPRELEASE on a normal container, but adding a quick upstart job to call ifdown -a does the trick (as observed using dhcpdump) [08:34] dimitern: awesome, that would help for the graceful shutdown [08:35] dimitern: but not forcible termination of host [08:35] dimitern: do we have to deal with vivid containers yet (systemd)? [08:36] voidspace, I suppose for vivid should be the same, just the job is different [08:38] dimitern: yep [08:38] voidspace, yeah, not forcible termination of the host [08:38] dimitern: anyway, your findings match mine [08:38] dimitern: that graceful shutdown doesn't release but an explicit ifdown does [08:40] voidspace, yes indeed [08:42] dimitern: fixing the graceful shutdown case would be a big step forwards [08:48] voidspace, yeah, and it's easy to do I guess [08:49] voidspace, that's the job I verified to work: http://paste.ubuntu.com/11667420/ [08:51] my tests so far were with a normal lxc container, now trying on maas [08:51] cool [08:51] looks good [08:55] voidspace, it works! [08:56] just deploying a container on maas and injecting the shutdown job causes it to trigger ifdown on shutdown (e.g. destroy-machine 0/lxc/0 --force) [08:57] dimitern: awesome [08:57] Ship It! [08:57] voidspace, I haven't even proposed anything yet :) [09:14] fwereade: thx for the hint with the bulk calls, thats a better approach [09:39] gsamfira, hey there [09:39] gsamfira, are you around for a quick chat? [10:52] morning [11:23] dimitern: heya [11:23] dimitern: I am now [13:14] Bug #1463399 opened: TestMachineAgentSymlinkJujuRun fails

[13:14] Bug #1463401 opened: FactorySuite teardown fails

[13:18] gsamfira: hey, so looks like bug 1451626 now has a fix ommitted? can you update launchpad to reflect the status of the bug? [13:18] Bug #1451626: Erroneous Juju user data on Windows for Juju version 1.23 <1.23>

[13:19] so we know the beta7 is good to release [13:19] (once CO passes) [13:19] CI [13:19] wallyworld: aren't there still open bugs? [13:20] wallyworld: ah nm, just saw your previous message to gsamfira [13:20] katco: just the cloud sigma one which we agreed coud be deferred as it's ehind a flag [13:20] wallyworld: the issue is juju doesn't build with that fix landed [13:20] oh [13:21] bollocks [13:21] http://reports.vapour.ws/releases/rules/239 [13:21] mgz_: katco: do we know the issue? is "someone" fxing? [13:22] we need go 1.4 for it, which curtis raised a ml thread about [13:22] wallyworld: ericsnow was working with sergey on a work-around [13:22] wallyworld: i will follow up in our standup [13:22] mgz_: i thought the idea of this bug fix was to remove the need for 1.4 by vendoring some other code [13:22] ty [13:23] i'll go away now :-) [13:23] katco: and let's no mention the soccer :-( [13:23] wallyworld: you lost? :P [13:23] not that i know of :-) [13:24] some would say so [13:24] wallyworld: aus was amazing in the first half [13:24] wallyworld: i thought you were going to take the us [13:24] katco: well, the usa goal keep was simply brilliant :-( [13:25] er [13:25] wallyworld: she really is... 2 or 3 huge saves [13:25] yup :-( [13:25] wallyworld: aussies right forward is a beast [13:25] ah, actual internation match [13:25] wallyworld: she is so fast [13:25] mgz_: woman's world cup [13:25] women's world cup rather [13:26] katco: sadly i didn't see the matc, just the highlights on the news [13:26] i was going to ask "which woman" :-) [13:26] Bug #1463399 changed: TestMachineAgentSymlinkJujuRun fails

[13:26] Bug #1463401 changed: FactorySuite teardown fails

[13:26] haha [13:38] Bug #1463399 opened: TestMachineAgentSymlinkJujuRun fails

[13:38] Bug #1463401 opened: FactorySuite teardown fails

[13:42] mgz_: Could you take a look at this? It looks like a coding error, but it also look intermittent: http://reports.vapour.ws/releases/2741/job/run-unit-tests-trusty-ppc64el/attempt/3176 [13:44] Bug #1463408 opened: TestRunCommand fails

[13:48] https://s-media-cache-ak0.pinimg.com/originals/1e/49/a9/1e49a91eeb15dcd60cf9a935a9b70e0e.jpg <-- google hangout [13:49] abentley: looking [13:52] abentley: I can't see how a build issue like that could be intermittent [13:52] most confusing [13:53] mgz_: Me neither, but if you click "next", the next attempt got further. [13:53] is the clock skew somehow making us not run all the right code? [13:53] but the next run doesn't have clock skew... [13:53] are they run against different machines? [13:53] Bug #1451626 changed: Erroneous Juju user data on Windows for Juju version 1.23 <1.23>

[13:53] Bug #1463420 opened: Zip archived tools needed for bootstrap on winows [13:54] nope, both .137 [13:55] abentley: my best guess is our script cleanup is not good enough [13:56] mgz_: Yes, that could be it. [13:56] mgz_: The clock skew can be explained because the second run happened later. [13:57] yeah, with the same tarball [14:08] * mgz_ pokes fun at bogdanteleaga for tyoping windows as 'winows' [14:08] it's like a small fish [14:09] (thanks for filing the bug :) [14:12] mgz_: oops :) [14:23] Bug #1449210 opened: cloudsigma index file has no data for cloud

[14:53] Bug #1463439 opened: golang.org/x/sys/windows requires go 1.4

=== kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [15:27] ericsnow: I was thinking of putting the plugin stuff in a directory under procmanager, just to try to keep things contained some. What do you think? [15:29] Bug #1228243 changed: juju provided peer relation leader feature

[15:29] Bug #1463455 opened: package github.com/juju/txn has conflicting licences

[15:30] natefinch: sounds good [15:49] natefinch: was bug 1424901 fixed with our latest log changes? [15:49] Bug #1424901: Agents don't sent logs to any rsyslogd unless all targets are available

[15:53] katco: not likely. I didn't change rsyslog at all [15:53] katco: at least functionally... just cleaned up the API of the function [15:55] natefinch: yeah, not the lumberjack stuff... i thought you had coordinated around rsyslog though? [15:56] katco: wwitzel3 did most of the rsyslog work. I don't know the specific details of the code. [15:56] natefinch: k ty. wwitzel3, any comments? [15:58] katco: although, this might be the Go syslog stuff, which gsamfira wrote [15:59] I think wayne just did the receiving side [15:59] IIRC [15:59] I don't remember what I did for rsyslog [16:00] defensive amnesia, it's understandable [16:00] hah [16:01] wwitzel3: no worries. just wondering if we could close out that bug [16:01] katco: I betcha it still exists [16:01] my guess is no, it looks valid [16:02] the package hasn't been updated since way before that bug was filed [16:05] wwitzel3, katco: yeah, looks like any error connecting will exit out: https://github.com/juju/juju/blob/master/worker/rsyslog/worker.go#L203 [16:08] natefinch: ty [16:08] natefinch: maybe comment on the bug since you went through the trouble to find that line? [16:09] natefinch: make sure you pin the GH link to that revision so its a perma-link [16:10] katco: I copied the link, but how do I pin the revision? I was actually thinking that it would be easy for that link to get stale [16:10] katco: nvm I got it [16:11] dammit, I wish you could edit bug comments on launchpad :/ [16:11] natefinch: can't you? [16:11] natefinch: or do you mean comments which aren't yours? [16:11] katco: I mean my own. I don't see a UI to do anything other that "hide" [16:12] I just make sure everything I do is perfect the first time. [16:12] wwitzel3: ahh, that was my mistake [16:12] :) [16:12] wwitzel3: "i disagree!" /slap [16:13] katco: actually, I just shout No .. I disagree is too formal [16:13] haha [16:19] ericsnow: you are frozen === redelmann is now known as rede|eateateatea [16:36] Bug #1463480 opened: Failed upgrade, mixed up HA addresses

[16:39] dammit [16:39] ah well [16:39] bootstrapped without allocatable addresses on [16:48] katco: wwitzel3, natefinch. I see menn0 added the prune files to github.com/juju/txn as agpl. the project is LGPL. Can you confirm this is a mistake? Would you accept my patch to change them to LGP? [16:48] LGPL? [16:49] sinzui: I'm sure it was a mistake [16:49] sinzui: ditto [16:49] fab. I will take care of this [16:59]