[00:06] thumper: grrr [00:06] this canWatch("") thing is really pernicious [00:06] gonna take some more time [00:06] * thumper looks in a dictionary [00:07] keep finding more test cases that fail whenever I make AuthAlways demand a valid tag [00:07] heh [00:07] it will be worthwhile [00:07] you're doing a good job [00:07] keep it up :) [00:07] now that's what I call Managing :-p [00:27] and Github is broken... [00:27] Storage server temporarily offline. See http://status.github.com for GitHub system status. [00:28] the graphs on that page show a sudden spike in Exceptions [00:30] I'm getting random prs going offline e.g: https://github.com/juju/juju/pull/499 [00:31] and https://github.com/juju/juju/pull/517 [00:32] can others see those prs? [00:32] oh, haha menn0 I just read your messages above [00:32] that would explain it [00:33] haha [00:33] status.github.com is now broken too :) [00:33] "Service Unavailable" [00:33] it's back [00:34] and now they have a note that they know something is wrong with some repos [00:36] awesome [00:37] thumper: my merge passed its test run but CI was unable to perform the merge because the repo on Github is borked ("Repository offline") [00:38] thumper: once Github is back will a manual merge be possible? [00:38] hmm... [00:38] I'd say go with CI doing it again [00:39] github say some repos are borked? [00:41] thumper: yep. See the email I just forwards to juju-dev. [00:41] thumper: the web stuff seems to be fine but interacting with the repo isn't working. [00:42] :( [00:42] thumper: it's back again [00:44] can someone have a quick look over this? It's the 1.20 backport of the tools version change that's going in to trunk. https://github.com/juju/juju/pull/538 [00:59] thumper: the bot won't pick up the PR that it's already tested [00:59] thumper: any chance you can click the merge button (I thought team leads could do this) [00:59] thumper: the tests passed here: http://juju-ci.vapour.ws:8080/job/github-merge-juju/328/ [01:00] thumper: the PR is here: https://github.com/juju/juju/pull/535 [01:01] wallyworld_: do you know how to kick this bot? [01:01] wot [01:03] bot is kicked [01:04] wallyworld_: ta [01:04] nice [01:04] you just need a "Build Failed: blah" comment [01:04] to tell the bot that a $$ $$ is valid [01:05] a second $$ $$ i should say [01:45] thumper: could i get you to look at this pr. it's a 1.20 only fix to address an lxc startup issue https://github.com/juju/juju/pull/539 [01:45] ack [01:45] ta [01:48] thumper: menn0 waigani https://github.com/juju/juju/pull/540 [01:49] ^ quite a nice solution i think [01:50] * thumper afk for bit from 2pm [02:03] axw: once you finish your maas branch changes, i just wanted to have a quick chat about copying tools [02:03] wallyworld_: sure [02:03] ta, just ping me [02:03] * bigjools cracks joke about copying wallyworld_ [02:04] * wallyworld_ tells bigjools to FO [02:08] wallyworld_: changes uploaded, ready to chat when you are [02:09] axw: i'll just lgtm first, one sec [02:11] axw: i'm still not sure why we need to pass in the series to the tools match, when we get the series from the tools we are matching on. the only reson i can see ottomh is so that we get the error if there is more than one series [02:12] wallyworld_: ah, right [02:12] I don't know why I did that now [02:13] wallyworld_: I've taken it out, that was nonsense AFAICT [02:13] ok, i've marked it as lgtm [02:13] thanks [02:13] join you in stand up [02:14] axw or wallyworld_: can you do a 10s look at this please? https://github.com/juju/juju/pull/538 [02:14] sure [02:14] 10, 9, 8, .... [02:14] it's the 1.20 backport of the agent.conf tools version change that just went in [02:23] axw: thanks [02:23] np [02:51] jcastro: https://plus.google.com/102738380796586573408/posts/BD1bYop5x7z [02:52] (the post I got you to review) [02:52] wallyworld_: ^^ finally published [02:52] axw: \o/ - i was meaning to ask you about that but kept forgetting [02:53] wallyworld_: was waiting for a new 1.20 release [02:53] ah, yes [02:56] axw: appears to be truncated [02:56] Work on llgo has been progressing, mostly due to Pe... [02:57] oh ffs [02:57] the link dropped [02:57] davecheney: thanks, fixing [02:59] jcastro: wallyworld_: davecheney: https://plus.google.com/+AndrewWilkinsTheFirst/posts/EfTDNXS4SET [03:16] davecheney, wallyworld_: bug 1358078 sorted for trunk and 1.20 \o/ [03:16] Bug #1358078: cmd/juju: juju bootstrap --upload-tools on a fresh environment triggers upgrade mode

[03:16] great :-D [03:16] thank you [03:17] nnnice [03:55] wallyworld_: just for you :) https://github.com/juju/juju/pull/541 [03:55] oh goody [03:57] thumper: if you have a momemnt, i've replied to your comments, https://github.com/juju/juju/pull/540 [04:10] davecheney: ack [04:11] wallyworld_: thanks for the review. merging now. [04:12] np, thaks for fixing [04:14] thumper: thanks for the review [04:14] one more coming up real soon now [04:14] kk [04:16] it's very similar [04:17] what I think happened is we started out with the common.AuthFunc [04:17] which says "this authoriser" can read/write/view/etc this entity (tag) [04:17] but common.Environ{,Machines}Watcher are really "global" [04:17] things [04:18] this is also indicatated that Authtorizer.AuthEnvionWatcher is not derived from the entity of the authoriser [04:18] it's actually some special permission bit stored in the database [04:20] menn0: nice cleanup of the upgrade stuff [04:20] +1 [04:22] davecheney: cheers [04:37] waigani: can you email matty and say you'll take over the EnvUser work? [04:38] axw, wallyworld_: do you know if fwereade is working this week? I normally leave before he would start [04:38] yes he is [04:38] ok.. [04:38] thumper: this branch: https://github.com/juju/juju/pull/432 [04:38] cheers [04:38] waigani: yes [04:38] thumper: okay, I was on call reviewer today. I'll make a start on it tomorrow. [04:39] waigani: can I get you to email him before EOD today, so he'll see it? [04:39] thumper: doing it now [04:39] cheers [04:39] waigani, davecheney, menn0: fyi - I have friday off [04:39] okay, thanks for the heads up [04:40] * thumper just realised that I also have a meeting friday morning... [04:40] hmm... [04:40] waigani, davecheney: party time! [04:40] * thumper emails rick_h__ et al [04:46] wallyworld_: aaaaaaand here's the 1.20 port: https://github.com/juju/juju/pull/542 [04:48] thanks menn0 [04:48] wallyworld_: thanks. I'll leave you alone for the rest of the day :) [04:48] promise,promises [04:59] thumper: https://github.com/juju/juju/pull/543 [05:03] davecheney: done, and now I'm off to guardians of the galaxy [05:03] \o/ [05:04] TheMue: danka [05:04] enjoy [05:05] i really hope this is the last little fucker [05:05] davecheney: thumper was gone when you replied so autocomplete got the wrong person :) [05:06] oopas [05:06] TheMue: sorry mate === urulama-_ is now known as urulama [05:37] wallyworld_: Fetched 8,775 kB in 5s (1,593 kB/s) [05:37] Reading package lists... [05:37] + sudo apt-get upgrade -y [05:37] is there any way to stop the bot [05:37] doing apt-get update/upgrade for every CI run ? [05:37] that isn't necessary [05:50] https://github.com/juju/juju/pull/545 [05:50] anyone for a little one ? [05:50] it's pretty uncontravesial [05:54] davecheney: apt updates are necessary to pull in all the deps required [05:55] wallyworld_: nah [05:55] why is it updating the kernel and building an initrd [05:55] the instances started to run the test aren't necessarily up to date [05:55] that is a waste of time [05:56] sure, but besides the kernel it also pulls in other dependencies that are needed AFAIK [05:56] morning all [06:19] wallyworld_: my memory is hazy, why do we need auto-upload on bootstrap? why not just require people to --upload-tools? [06:20] axw: from memory, it was "too hard" and the out of the box experience should be that it Just Works if there are no matching prepackaged tools available [06:21] wallyworld_: mk. I'm not sure it holds its weight given that it only applies to dev builds [06:22] it's a bit of a PITA to try to get it to work the same way in my new branch [06:22] i'm not personally wedding to the idea of it being automatic - it was done because of user requests [06:23] wedded [06:23] we can look to get your stuff landed and see if it can be tastefully added back in [06:23] wallyworld_, axw: IMO --upload-tools is pretty fundamentally broken [06:24] i wish we could drop it [06:24] but we've been told we can't [06:24] wallyworld_, axw: but the magical fall back to locally available tools is a good thing [06:26] fwereade: remind me why --upload-tools is fundamentally broken? [06:34] Morning [06:36] dimitern: I'm at a funeral this morning. So I'll start after lunch. :( [06:36] TheMue, oh :( alright then [06:37] dimitern: I would like to discuss your idea then. IsManual is special to machines, so I would place it at machiner.Machine, not agent.Entity. [06:37] dimitern: Will ping you then. [06:37] TheMue, ok, we'll discuss it [06:38] dimitern: Thanks [06:58] wallyworld_, anyway we can get whatever fix you guys deem appropriate for https://github.com/juju/utils/pull/22 in 1.20.x ? [07:00] Beret: i think so. by the looks of the comment from kapil, the approach needs to be re-thought. we can try and get it done for 1.20.6 [07:01] thanks [07:01] i'm hoping that 1.20.6 might be able to be released this time next week [07:01] +1 [07:01] we're trying 1.20.5 but from the looks of the bug fix list, it should be pretty solid [07:01] hoping so [07:01] we're still struggling a bit to inderstand fully the lxc issues being seen [07:02] that's the only thing really outstanding still right? (other than this apt retry thing) [07:02] there's a few other smaller bugs [07:03] Beret: if there's any extra info that can be provided for bug 1354027 that would be great eg contents of /var/lib/juju/containers when it fails [07:03] Bug #1354027: LXC was not created, no errors, no logs -> pending state.

[07:07] wallyworld_, ok, we'll see what we can do [07:07] thanks :-) [07:07] axw, sorry, I missed your question [07:08] fwereade: hey, it was [07:08] fwereade: remind me why --upload-tools is fundamentally broken? [07:08] axw, the biggest issue with upload-tools is that it's the core reason tools distribution was always so awful [07:08] axw, it was a separate code path written *really* early on [07:09] axw, and the developers were *always* using upload-tools [07:09] axw, and so the real code paths... well, they barely even existed, and certainly weren't mature, when we first released [07:09] axw, then users found out about upload-tools [07:10] axw, which obscures really important info, like *which damn build is running* [07:10] axw, but let them actually use juju [07:10] axw, so it got kinda promoted [07:11] axw, and hangs around our necks to this day [07:11] ok [07:11] axw, finding local tools of matching version and using those automatically, though? that's fine IMO [07:12] fwereade: with the auto upload stuff, I'm trying to avoid having providers call back into common bootstrap code to "ensure tools" [07:12] I think I can do it, it's just a bit messy [07:12] in my new branch, environs/bootstrap finds all the available tools, and presents them to provider's Bootstrap [07:12] that chooses an arch & series and reports that back [07:13] axw, it's always a tough call but I could probably get behind a bit of extra duplication across the providers if we actually simplify what's happening [07:13] common code then uploads if necessary [07:13] axw, that sounds good [07:13] axw, slightly better fit with what we do for normal machines [07:28] speaking of upload-tools, I think backup is broken if you use it (at least I'm seeing a path issue for mongodump that only seems to happen with upload-tools) [07:28] and that makes it a real pain to test changes to restore... [10:46] jam: TheMue: dimitern: standup? [10:47] sorry, brt [10:50] voidspace: dimitern, brt, === cliff-hm is now known as cliff-eat === cliff-eat is now known as cliff-hm [11:32] jam: I don't think you succeeded in pushing your changes [11:32] jam: github thinks that branch is identical to master [11:32] void [11:32] https://github.com/jameinel/juju/compare/test-local-backup [11:32] voidspace: master is, but 'test-local-backup' has the interesting stuff [11:32] jam: according to github compare "juju:master and jameinel:test-local-backup are identical." === gsamfira1 is now known as gsamfira [11:34] ooh, it looks like restore might be working against an amazon juju [11:34] voidspace: committing helps [11:34] backup failed until I linked in the commands, but restore has not failed in the same way that restore failed against canonistack [11:34] jam: :-) [11:35] local will definitely be faster [12:18] jam: I was booted out [12:23] jam: https://github.com/voidspace/juju/compare/backup-ssh [12:41] ericsnow: ping [12:41] ericsnow: have you worked on the old backup plugin? [12:58] back again (together with a heavy thunderstorm) [13:06] TheMue: welcome back, we missed you. How's it going? [13:15] jam: it’s ok, has been the father of a good friend I know for more than 30 years now [13:21] TheMue: do you have a bug number for the LXC IPv6 issues? [13:21] I want to raise it in the networking discussion. [13:23] jam: yep, https://bugs.launchpad.net/juju-core/+bug/1358376 [13:23] Bug #1358376: IPv6 connectivity of LXC containers

[14:00] natefinch, wwitzel3: standup? [14:01] ericsnow: yep [14:01] ericsnow: coming === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1358768 [14:18] natefinch, I just reported bug 1358768. Can you find an engineer to fix the regressions [14:18] Bug #1358768: No tools found in i386 and ppc64el unit tests

[14:32] sinzui: will do [14:34] natefinch: 1-on-1? [14:34] ericsnow: oh yeah, ok === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [17:35] dammit, I'm getting 500s from github trying to look at commits on juju/juju [17:36] natefinch: I was getting that earlier through the browser [17:36] natefinch: though everything through the git command line seemed to be working ok [17:36] natefinch: wwitzel3: i know they had some storage issues last night [17:36] doesn't help for looking at PRs [17:37] katco: ahh, probably some residual issues from that then [17:37] wwitzel3: https://status.github.com/ [17:38] wwitzel3: natefinch: 0:28 UTC: We're investigating problems accessing a small percentage of repositories. [17:41] katco, wwitzel3 : thanks === BradCrittenden is now known as bac [18:29] rick_h__: have some time today to talk about charm feature flags? We need to implement support for them, probably this week. [19:01] natefinch: sure thing [19:01] natefinch: free from now for the next couple of hours [19:01] rick_h__: half hour? trying to unblock CI [19:02] natefinch: rgr, shoot me a link when you're ready [19:06] sinzui: fix applied.... required revert of https://github.com/juju/juju/pull/536 [19:07] sinzui: I didn't look too deeply into the cause of the bug, possibly something simple... looks like we're restricting the list of returned tools based on the current architecture... but figured Andrew can fix it when he's on and re-submit. [19:08] thank you natefinch [19:18] sinzui: where do the CI machines keep godeps? I wrote a test that runs godeps and ensures dependencies.tsv matches what godeps outputs.... but the test fails in CI because it can't find godeps. === Ursinha is now known as Ursinha-afk [19:23] natefinch, godeps is not available. It is installed to create the tarball, then it is removed because Ubuntu doesn't want it packaged [19:24] natefinch, we need to add godeps to the makefile maybe to ensure it is available for tests [19:24] natefinch, or we tell ubuntu that godeps is now a requirement [19:26] sinzui: how can we run the tests if we don't run godeps first? Sorry, maybe CI was the wrong word... wherever the unit tests get run [19:27] sinzui: I presume there's a machine where we pull down the code, run godeps to set the correct revisions on all the repos, and then run go test. That's the machine I need to be compatible with my test [19:27] sinzui: see here: https://github.com/juju/juju/pull/495 [19:30] natefinch, we test the release, not the code. we test that tarball made in a previous step. [19:31] natefinch, run-unit-test runs make install-dependencies after unpacking the tarball under test to get the deps [19:32] natefinch, Since you name have a test that requires godeps, I think I can justify that the tarball include it. [19:43] sinzui: ok, thanks. Please dump it in $PATH or $GOPATH/bin - those are the only two logical places where developers would have it. [19:45] oh, natefinch, the tarball cannot contain /bin because then the tarball is not a source tarball. [19:45] natefinch, I think we need to change the test rules to build... [19:45] nm, we already call build [19:46] natefinch, I will make changes in a few hours to include godeps in the tarball. [19:46] I will ping you when it is ready [19:46] sinzui: thanks. This is just the tarball we dump on the test machine for testing... we wouldn't be including godeps in the package, right? [19:47] NO [19:47] natefinch, this is the real tarball [19:47] since golang cannot be trusted to always build the same tarball (Ubuntu's opinion) we make it once, we test it as the release, and if it passes, I can release it [19:48] We cannot tamper with the tarball's contents once we make it [19:49] sinzui: ok, sure. If ubuntu's rules require that we include a whole bunch of crap that the actual application doesn't even use, just because it's used to test the application, so be it. I'm tired of trying to fight that fight. [19:49] natefinch, that is indeed the reason they wanted it removed [19:50] natefinch, why doesn't the juju Makefile ensure godeps is installed? [19:50] natefinch, I can make that change too [19:50] sinzui: it looks like on july 7th, it was changed so that it wouldn't install it unless a certain env variable was set [19:52] natefinch, the Makefile or make-package-with-tarball.bash, or run-unit-tests? [19:52] sinzui: https://github.com/juju/juju/blob/master/Makefile#L36 [19:54] natefinch, sorry. I was looking at 1.20. [19:54] natefinch, okay, I will get this change into 1.20 and change run-unit-tests to call it [19:56] sinzui: the godeps build target I think will fail if you don't have the actual code.... possibly it'll just go download all the code for all the dependent repos. [19:56] sinzui: I think the latter [19:56] natefinch, I see it doing go get launchpad.net/godeps [19:56] natefinch, and I can add a step to install it if need be in run-unit-test. [19:56] sinzui: there's two steps, go get launchpad.net/godeps and then godeps -u dependencies.tsv [19:57] I see both in the current Makefile [19:57] sinzui: yes, the second one, godeps -u, will go get all the source code for Juju and set the repos up to be at the correct revision [19:58] (well, it'll get all the source code for juju that isn't under github.com/juju/juju) === urulama is now known as uru-afk [19:59] sinzui: *I* don't care that it'll do that.... just warning you that it will, in case that will either a.) fail, or b.) be a problem for some other reason [20:00] natefinch. The making of the tarball 15 minutes before is more likely to catch the problem [20:01] natefinch, when thumper drops a tab, the tarball doesn't build, testing ends immediately because there is nothing to release [20:01] natefinch, So i think think this test will always pass in ci [20:02] natefinch, and the git-merge-juju will do the same since the tarball is made before the unit tests are run from it [20:04] sinzui: This test will *currently* always pass CI, I believe.... but it could fail if we stop running godeps -u first, which is a nice thing to test. Mainly it's for developers who may forget to run godeps -u === Ursinha-afk is now known as Ursinha [20:15] rick_h__: do you have time now? [20:15] natefinch: sure thing [20:15] rick_h__: https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1 === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [20:34] fwereade: around? [21:28] * thumper is off to see the physio at 10 [22:11] thumper: AdminUser is defined as a const string in state. Do we want to ditch that and make AdminUser a names.UserTag("admin") ? [22:11] thumper: or do we want to build the tag everywhere AdminUser is used? [22:12] i.e. names.UserTag(state.AdminUser) [22:12] doh just saw thumper is at physio === mup_ is now known as mup [22:42] waigani: back [22:42] waigani: no, we don't want to do that [22:42] waigani: I actually have a directive to change the admin user to be the username of the user bootstrapping [22:42] thumper: okay, I've just built the usertag where I needed [22:43] thumper: I commented another question on the PR for you [22:43] which PR? [22:45] thumper: 432 [22:45] thumper: https://github.com/juju/juju/pull/432/files [22:45] kk, otp with hazmat [22:46] thumper: basically, are we ready to append env to usernames i.e. bob@local and should I look at doing that in this PR? [22:46] waigani: not yet [22:46] followed by "it depends" [22:48] thumper: I'm good with "not yet"