=== revagomes_ is now known as revagomes [00:20] nice, got my gojsonreference reimplementation built and passing tests [00:21] now need to get tests on gojsonschema passing again [00:24] bodie_: o/ === thumper-otp is now known as thumper [00:35] * thumper takes a big breath [00:35] * thumper exhales [01:00] thumper: davecheney: are we just using the standup channel? [01:00] waigani: sure [01:01] yup, see you back in the hangout [01:04] morning all [01:07] morning [01:48] man looking at all the discussions that include menn0 and thumper in mailing lists is like reading a webcomic, we need to wait 12 hs between each episode [01:49] perrito666: welcome to canonical [01:51] I've added some user docs and apparently I need to let evilnick know about them. What is the best way to do that? [01:54] thumper: $ juju user detail foobar; #output: username: foobar [01:54] that is one useful cmd! [01:54] waigani: exactly, which is why we want display name :) [01:55] and later... groups and stuff [01:55] waigani: we probably also want 'date created' etc, and other items not yet in the document [01:55] thumper: i'll throw in anything i can find and we can then cut back [01:55] except maybe password ;) [01:56] waigani: add in some TODOs for when we modify the doc [02:03] thumper, I have deployed with the last built juju twice. [02:03] and? [02:03] thumper, I don't see the issue universally reported by ci's tests [02:04] I also know that there were no stale jenv files because I reset all the JUJU_HOMEs a hour before [02:04] sinzui: using upload tools? [02:05] never for cloud tests. only local host is allowed to use upload tool [02:06] thumper, I am reading all the shell env hoping to find a 1.18 invocation of juju that could cause the problem [02:12] sinzui: gee, wouldn't it have been useful to have a stack trace there... [02:13] yes it would. I wish I could trust juju not to reveal keys when in --debug [02:13] thumper, I was trying to get you such a stack trace when the bugger succeeded [02:22] davecheney: this makes me happy. http://juju-ci.vapour.ws:8080/job/walk-unit-tests-ppc64el-trusty-devel/ ppc tests more reliable than amd64 right now [02:23] wallyworld_: it makes me happy as well :) [02:24] amd64 failures are down to random io timeouts etc [02:27] \o/ [02:27] congrats davecheney and wallyworld_ [02:28] thumper: and axw [02:28] he saved our bacon [02:28] thumper: axw as well [02:28] and axw :-) [02:28] he did a lot [02:30] winning [02:30] the bot is way happier lately too [02:30] glad the work has been useful [02:30] i noticed [02:31] every time I see a merge attempt email I have a heart attack, thinking there's going to be a new intermittent failure [02:31] axw: same [02:31] negative conditioning [02:31] just need to make sure everyone does this once in a while ;) [02:33] axw: it has been incredibly valuable, kudos [02:33] davecheney wallyworld_: the ppc64 test instance is nailed up right? I wonder if that has anything to do with stability [02:33] as opposed to amd64 which is spun up/down each time [02:33] axw: yeah [02:34] axw: well, when maas works on ppc then maybe we can introduce that element of randomness [02:34] i can't say it's high on my list [02:34] heh :) [02:50] thumper, I am convinced there is a bug test code that ensures the right version of juju is bootstrapped. [02:50] thumper, please don't revert [02:50] kk [02:57] thumper, I found the problem. I don't know how ti fix it yet, but I was able to feed 1.20-beta1 into the test suite and find the bad method [02:58] oh? [03:20] thumper: https://github.com/juju/testing/pull/4 [03:21] *cough* when you have a sec [03:21] * thumper looks [03:24] axw: was otp before. if i can get juju tests passing with mongo 2.6, initially that will be on a nailed up ec2 instance but then we could switch to an ephemeral instance and see how well it works [03:25] wallyworld_: okey dokey, sounds good [03:26] got some fundamental test failures to sort out. once root cause found, should then just work [03:26] i can bootstrap an env with mongo 2.6, just not get passing tests [03:27] wallyworld_: did it build properly with TLS [03:27] ? [03:27] yeah [03:27] bbs, school run [03:27] i've heard you have to sacrifice a newborn to make that happen [03:28] seemed to work ok [03:28] maybe you need to add more children [03:28] could bootstrap a system [03:28] test failure related to a permission problem with listDatabase() ops and such [03:29] bitch to debug remotely so building locally [03:30] davecheney: I'm just about to go and have a coffee... but I'm curious, what was the problem with the code matching yesterday? [03:32] thumper: it's pretty funny, in a not funny kind of way :) [03:39] thumper, I have a success. I will attempt to erase CI's recent memory of this revision to restart all the tests [04:20] thumper: SimpleMessage, the message isn't a string, it's a regex [04:20] because i had included parethesis in the mathcing text [04:20] sadface [04:21] davecheney: https://github.com/juju/errors/pull/2 [04:21] davecheney: ahh.. [04:22] axw: reflect.DeepEqual does work [04:22] axw: it really just isn't what I tend to think of when wanting identity [04:22] thumper: if you are happy then I am happy [04:22] perhaps I just have to accept it [04:22] i know you've explained to me a bunch of times [04:22] but I still don't understand what you need [04:22] or what it does [04:22] so if you're happy [04:22] then i'm happy [04:22] davecheney: the tests pass, so I'm happy [04:23] case closed [04:23] thumper: i'll take quick peek at what reflect.DE does for interface types [04:23] davecheney: if there is a short circuit success pass then I'm extra happy [04:24] but in reality, this function isn't called all that often [04:24] so it will never be any form of bottle-neck [04:24] thumper, deploy is fixed, bug upgrade has a panic https://bugs.launchpad.net/juju-core/+bug/1323937 [04:24] thumper: it's even nicer than that [04:24] teo secs [04:24] sinzui: upgrade panics? [04:24] sinzui: ah... new version [04:24] arse [04:25] damn... [04:25] http://golang.org/src/pkg/reflect/deepequal.go?s=3380:3419#L128 [04:25] sinzui: ok, I have a plan [04:25] sinzui: we keep the code, but revert the version number to 1.19.3 [04:25] reflect.ValueOf returns a reflect.Value that represents the concrete type of the interface value [04:25] thumper, the details imply simple streams...because 1.18.1 canno even bootstrap when it discovers that version exists [04:25] sinzui: we keep the behaviour of the numbers until 1.20.0 has been released [04:25] thumper, yeah. I was thinking the same [04:26] sinzui: really? hmm... [04:26] wallyworld_: thoughts? [04:26] thumper, I can only guess. I am tired [04:26] wallyworld_: finding tools versions where versions aren't parsable by old code? [04:26] hmmm [04:26] sinzui: I'll submit a patch to make the current version go back [04:27] sinzui: because otherwise 1.18 clients will panic when getting a new version number it can't handle [04:27] so reflect.DE gets the underlying values, and comparest their types, [04:27] thumper: i think we need current-1 to be able to find tools fir current to allow upgrades [04:27] thumper, could the - be the issue? could 1.20beta1 be acceptable? [04:27] which is what we were doing by snarfing in the first word of the interface struct [04:28] sinzui: this will be the cause of the upgrade failure [04:28] sinzui: let me fix it [04:30] It looks like any writes to command context (Infof, Verbosef) go to stderr, is this expeceted? [04:32] jimmiebtlr: yes [04:32] jimmiebtlr: some commands have strict format output that goes to stdout [04:32] jimmiebtlr: we wanted to make sure that stdout says parsable by tools expecting that strictness [04:32] jimmiebtlr: so extra info goes to stderr [04:33] ok [04:33] and to be consistent, we always send to stderr [04:34] so for instance from the add-machine command would the output "created machine X" be expected to output to stderr or stdout? [04:35] jimmiebtlr: I'd expect it to go to stderr for the above reason [04:35] ok, thanks [04:41] Rietveld: https://codereview.appspot.com/93570046 [04:41] wallyworld_, axw, sinzui, anyone... ^^^^ [04:41] fixes the broken upgrades of trunk [04:41] ok [04:41] by reverting version from 1.20-beta1 back to 1.19.3 [04:42] doh [04:42] yeah... [04:43] the 1.18 agents need to be able to parse the new version updated in config without dying :-) [04:43] my boo-boo [04:44] thumper, when I release 1.20.0 next month. I will then set the version to 1.21-alpha1? [04:45] sinzui: yes, or 1.21-dev1 [04:45] what ever flicks your switch [04:45] alpha, bravo, charlie, delta, echo, ... [04:45] finish with a foxtrot [04:46] albatros [04:46] sinzui: you could change the naming scheme with every release :-) [04:46] 1.21 - birds [04:47] I am off to bed. CI is actually just finished the last revision. the 1.18.x upgrade tests were true failure. canonisatacks failure was swift related [04:47] sinzui: thanks [04:49] oh, wallyworld_ I think I need to revert the ppc64el deb -> ppc64 tgz tool. This failure happen after to remove support for the ppc64el tool http://juju-ci.vapour.ws:8080/job/local-deploy-trusty-ppc64/10/console [04:50] looking [04:53] sinzui: what's inside the deb? ++ wget -q http://juju-ci.vapour.ws:8080/job/publish-revision/lastSuccessfulBuild/artifact/juju-core_1.20-beta1-0ubuntu1~14.04.1~juju1_ppc64el.deb [04:54] ppc64el.tar.gz or ppc64.tar.gz [04:54] should be the latter for juju to find it [04:54] if i understand the issue correctly [05:02] * bigjools wonders what thumper has been doing to get an icky taste in his mouth [05:02] :P [05:17] bigjools: management [05:17] +1 [05:29] bigjools: sorry, you set that one up, I just needed to take a run up [05:29] davecheney: quite all right [05:45] i've been deep diving in to how upgrades work and I've got a handle on most things [05:46] there's just one bit I'm not sure of [05:46] has anyone got 5 mins to help? [06:02] fwereade: axw: are we meeting to discuss bug #1215579 ? [06:02] <_mup_> Bug #1215579: Address changes should be propagated to relations

[06:02] I don't see dimitern yet [06:02] jam: I was about to join, but I guess we should wait for dimiter [06:07] I'm there, but just to be around if someone joins [06:09] axw: fwereade is here now [06:09] okey dokey === Ursinha-afk is now known as Ursinha === vladk|offline is now known as vladk [08:08] fwereade: ping [08:08] wwitzel3, pong [08:09] fwereade: you have some time to discuss presence things? [08:09] wwitzel3, sure :) [08:09] wwitzel3, moonstone? [08:09] fwereade: k, let me grab my coffee and I'll be in moonstone. [08:10] * fwereade does same [08:16] jam, fwereade: networker API facade: https://codereview.appspot.com/98600047 [08:18] morning all [08:19] voidspace: hiya [08:22] rogpeppe: hey roger [08:22] voidspace: how's tricks? [08:23] rogpeppe: not bad, although today's task is working out why turning on replica set for tests makes the "no reachable servers" problem about a million times worse [08:23] rogpeppe: so not much fun :-) [08:23] rogpeppe: how's jazz-land? [08:25] voidspace: morning [08:26] wwitzel3: hey, morning [08:26] wwitzel3: sleep any better? [08:26] voidspace: sadly no [08:27] wwitzel3: :-( [08:27] I thought being around this early wasn't a good sign [08:28] grabbing coffee, back in a minute [08:29] voidspace: I was able to get a nap in the afternoon yesterday for about an hour and I tossed and turned for about 5 hours this evening for maybe 2 hours of total sleep. [08:30] voidspace: I'll probably take a sleep aid tonight, so I don't become a zombie. [08:35] wwitzel3: yeah, sounds like a good idea :-/ [09:19] fwereade: wrt https://code.launchpad.net/~jimmiebtlr/juju-core/add_machines_tag/+merge/221013 are we wanting to expose things as tags to the CLI? [09:25] jam, certainly not [09:25] jam, not sure where that came from [09:25] yeah, I didn't see an associated bug, and you've mentioned to me that we didn't want it [09:25] jam, we have a bug that debug-log uses tags (grarrrr) [09:25] jam, I assigned it to thumper but forgot to mention it to him, I should do that [09:25] I'm not personally all that happy with bare numbers for machines, but if we want to not use tags, then we shouldn't [09:27] vladk: I have some feedback for https://codereview.appspot.com/98600047/ [09:28] I haven't reviewed everything, but I did give a bit of a "here are some stuff that we need to iterate one" [09:28] on [09:31] fwereade: for changing Login so that it goes via "https://host:port/ENVUID/api" sort of URLs. Would you be averse to using a different Mux? One that was path aware? (like github.com/gorilla/pat) ? [09:32] I'm not sure I like Pat, as it looks to be doing a separate global hash map for extra data [09:32] (It at least pulls in gorilla/context which does that exact thing) [09:32] jam, I don't have an opinion; am happy to follow your judgment on that [09:32] but it seems a bit of "we could roll our own" that would be less flexible in the long term [09:33] though our needs today are very modest === luca__ is now known as luca [09:37] jam, I'm all for pulling in well-defined battle-tested solutions from elsewhere [09:37] jam, hand-hacking the perfect tool with zero fat is a beguiling approach but by no means necessarily optimal [09:38] fwereade: bringing in tons of dependencies and their own cruft isn't always great, either. but Mux seems like something there are a few possible solutions around. [09:39] jam, sure, some degree of taste and sanity needs to inform these decisions [09:41] fwereade: I found http://www.alexedwards.net/blog/a-mux-showdown though it is interesting that now Pat is gorilla/pat and imports gorilla/mux, so I'm not sure why to use Pat over Mux if we go that route [09:43] weird, apparently there is also https://github.com/bmizerany/pat [09:43] which seams a bit lighter [09:59] fwereade: for URLs, should it be UUID or Tag ? [09:59] eg: /environ-dead-beef/api/ [09:59] or [09:59] eg: /dead-beef/api/ [09:59] or possibly [09:59] eg: /environ/dead-beef/api/ [10:00] it feels a bit like putting the environment- prefix in the URL isn't needed. [10:01] (I should be clear that the tag has the full environment- prefix, I always want to spell it with the short name) === vladk is now known as vladk|offline [10:06] axw: ping [10:06] if you're still around [10:06] voidspace: heya [10:06] I may disappear soon, but I am here now [10:06] axw: hey, you wrote the code in this CL [10:06] https://codereview.appspot.com/88350043/patch/40001/50005 [10:06] * axw hides [10:06] haha [10:06] no, it's all good [10:07] it includes the code that *doesn't* enable HA for local provider [10:07] right [10:07] the problem that necessitated that appears to have disappeared [10:07] so I'd like to just enable HA for local provider [10:07] shouldEnableHA includes the following comment [10:07] +// Eventually this should always be true, and ideally [10:07] +// it should be true before 1.20 is released or we'll [10:07] +// have more upgrade scenarios on our hands. [10:08] axw: as I'm going to remove shouldEnableHA *before* 1.20 (i.e. now) [10:08] is it correct that I don't have to consider any *additional* upgrade scenarios - the existing code will handle everything [10:08] voidspace: correct [10:08] axw: awesome :-) [10:08] thanks [10:08] voidspace: I assume you were able to reproduce the bug before, but can't now? [10:09] axw: wallyworld was able to reproduce before and can't now [10:09] ah great [10:09] sweeeet [10:09] voidspace: nice! [10:09] axw: so we'll enable it - and then I'll email juju list and warn people to try it [10:09] natefinch: yep, morning :-) [10:09] voidspace: morning :) [10:09] thanks, SGTM [10:09] very much [10:10] natefinch: enabling replica sets for tests seems to be more problematic, but I'll start digging into that once this mp is ready [10:11] voidspace: we might have to punt on that if it gets too big, but we should at least give it the old college try before giving up. [10:11] natefinch: yep [10:11] natefinch: although it will be annoying to have a production check for replica sets merely to accomodate the test environment [10:12] voidspace: well, I think we can do it a different way. Just mock out a function in test or something. [10:13] natefinch: ah yes [10:15] jam, I think the API can just be uuid [10:15] jam, sorry, the *URL* can just have the UUID [10:16] right [10:16] I understood you === vladk|offline is now known as vladk [10:45] dimitern: are you back ? [10:45] standup ? [10:46] jam, yes, brt === Ursinha is now known as Ursinha-afk [10:46] fwereade: are you coming to our standup today ? [10:47] jam, why not :) [10:48] fwereade: do you know the distinction between agent-state and agent-state-info? in both the cases of ensure-availability and status .. agent-state-info seems to have the correct information, even though agent-state is reporting "down". [10:49] wwitzel3, the SetStatus has a status "enum", and an info string, and we tacked on a map for more info later [10:49] fwereade: I'm wondering if having the AgentPresence check inspect agent-state-info for hints about the status (ie is it really down?) might be ok? [10:50] wwitzel3, the difficulty is that agent-state: down is hacked in in the status api, and we don't send the real value of agent-state-info down in status [10:50] wwitzel3, I don't *think* it would help [10:50] fwereade: ahh ok [10:50] wwitzel3, agent-state might be a better bet, though [10:51] wwitzel3, if it's never yet set a value, it's probably not there yet [10:51] fwereade: right, makes sense [10:51] wwitzel3, although even that is imperfect, because the pinger will start a bit before the machiner gets round to setting started [10:51] fwereade: good news is the rename worked just fine, compiled and tests pass [10:51] wwitzel3, *and* we should expect that the set of statuses, and when they're set, will change as well [10:52] wwitzel3, cool === vladk is now known as vladk|offline === vladk|offline is now known as vladk [11:15] fwereade: it's in a bit of a shoddy state, but I've got addresses flowing end to end now [11:16] fwereade: I modified AliveHookQueue to do something similar to changedPending- does that sound terrible? [11:16] fwereade: AliveHookQueue selects on another channel, and then sets a flag to say that it wants to send a relation-address-changed hook next [11:20] axw: that was quick! Thanks. [11:20] no worries [11:21] Nice when a CL is mostly code removal. [11:21] deleting code is one of my favourite things [11:21] :-) [11:22] "if you think writing code is awesome you should try deleting code!" [11:22] heh :) [11:23] :) [11:23] I deleted a bunch of code yesterday... felt great [11:23] I kind of get the appeal of dentistry now, too... [11:23] hah [11:24] I kinda like my teeth [11:25] morning [11:26] perrito666: morning [11:26] perrito666: morning === vladk is now known as vladk|offline === Ursinha-afk is now known as Ursinha === vladk|offline is now known as vladk === vladk is now known as vladk|offline [11:48] rebooting to get local provider working again :-/ [11:48] ERROR cannot use 37017 as state port, already in use [11:54] voidspace, ps aux | grep mongo [11:55] hazmat: I had this yesterday, killed mongo - still got the same error [11:56] voidspace, do see port 37017 in output of sudo netstat -tulpn [11:57] hazmat: not after rebooting :-) [11:57] hazmat: I'll try next time, happened yesterday too [11:57] voidspace, i'd try juju destroy-environment --force on it [11:59] thanks [12:02] yeah, there's a few things that aren't always cleaned up perfectly in the local provider.... we should probably do some work to try to make it more reliable, because it does tend to get stuck like that, whether it's mongo or lxc or whatever. You know, when we have spare time ;) [12:04] natefinch: local provider still seems to work with my changes, and I have an LGTM [12:04] natefinch: so merging and switching to looking at tests after lunch [12:05] voidspace: awesome === vladk|offline is now known as vladk [12:09] voidspace, if its not working for you yet, i'm up for doing a g+ screenshare to debug [12:09] * hazmat reads backlog and realizes its already working [12:09] cool [12:17] rogpeppe, do you still have that api parser code handy? the one that extracted an api listing from the src? [12:17] hazmat: yes [12:17] hazmat: but recent changes mean that it's not going to work for much longer (assuming it does still) [12:18] rogpeppe, bummer [12:18] hazmat: the API is not longer statically determinable [12:18] s/not/no/ [12:20] the refactoring that's been going on in api makes it much harder to determine what the full api is and identify the delta for client construction [12:22] i guess i should be using godoc instead of src.. ala http://godoc.org/launchpad.net/juju-core/state/api [12:49] jam, natefinch fwereade Can someone look into this regression, bug 1324110 [12:49] <_mup_> Bug #1324110: go get cannot find github.com/juju/testing/logging

[12:51] sinzui: I see github.com/juju/testing just fine, are you sure you are "go get" ing all the new dependencies? [12:51] people have been breaking out a lot of the core code into libs [12:52] ah, hmm... lo testing/logging [12:52] that I don't see [12:52] jam, CI runs this [12:52] go get -v -d launchpad.net/juju-core/... [12:52] sinzui: I think the bug is that something was removed and we didn't notice because go build leaves the old artifacts around [12:53] and it say github.com/juju/testing/logging is missing I see testing/ but mote testing/logging [12:53] sinzui, jam: this can be related to my current change in https://github.com/juju/testing/pull/5 . I am also waiting on a review for https://codereview.appspot.com/92660046 . After that, I can fix the dependencies on core [12:53] sinzui: sure, I think it used to exist there, and it got moved, and some imports moved with it, but we missed this one because everyone running the test suite still had it from before it was moved [12:53] frankban: the issue is that trunk is currently already broken [12:53] jam, understood, [12:54] because it imports a module [12:54] and updated godeps [12:54] to point to one that didn't have it anymore [12:55] fwereade, mgz, natefinch : on a whim inspired by natefinch I added an FAQ yesterday. Are 3 FAQ's worth including? I expect it to grow: https://codereview.appspot.com/98650043/ [12:56] morning john [12:56] bodie_: o/ [12:57] fwereade: I think this one is ready to go too: https://codereview.appspot.com/92630043/ [12:59] jcw4: well, that's useful info at least [12:59] frankban: can you either fix the import or revert the godeps so that trunk can build again? [12:59] I kind of think it's stuff that should just be in HACKING rather than faq form [13:00] mgz: I'm open to whatever seems best [13:01] jcw4: landing as is seems best for now, as I'm also rewriting things [13:01] 2783 Francesco Banconi 2014-05-23 [merge] [13:01] [r=gz] Update the github.com/juju/testing dependency. [13:01] is probably the one that broke ups [13:01] easy to bring different bits together later [13:01] mgz: excellent [13:01] jam: yeah, I've seen that [13:01] I'll fix [13:02] mgz: should we change the bot to always do a cleanroom build? so stuff like this can't land [13:02] maybe... I actually need the go get to work... which requires tip juju/testing to not be borked I think [13:02] I don't think it would add huge amounts of compile time overhea [13:02] d [13:02] jam, well, my bot-test just broke on it [13:02] mgz: bzr merge -r 2783..2782 [13:02] so... EOW [13:02] End of Week ? [13:02] Hopefully! [13:03] mgz: its only Wednesday :) [13:03] mgz: or you mean the github version will do cleanroom builds [13:03] jam: right, git on jenkins is from scratch each time at present [13:03] jcw4: LGTM'd [13:04] natefinch: ta [13:13] hm, go get really screws things [13:13] if any import in any tip of a dep is changed, it will fail [13:17] jam, mgz so I am not sure how to dupe that problem, but there are two places in the code which still try to import testing/logging [13:18] one is golxc, and I have a fix here: https://codereview.appspot.com/92660046 [13:18] frankban: rm -rf $GOPATH/pkg [13:18] then when you build again, it should fail [13:18] the other is juju-core testing/testbase/log.go, which is easy to fix [13:18] frankban: I'm looking at the second [13:19] I guess we land the golxc one, then I can bump that dep as well [13:19] will review [13:19] currently I'm missing PatchEnvironment.. [13:20] mgz the second is something like http://pastebin.ubuntu.com/7536578/ [13:21] frankban: ta [13:21] mgz: Once the golxc land, we should update golxc and github/juju/testing dependencies in juju-core, aplly the patch and hopefully we are all using the new testing version [13:22] frankban: lgtm [13:22] mgz: landing it [13:22]