[01:12] wallyworld: I can't get TestUniterUpgradeConflicts to fail at all, and it's been passed by the landing bot... [01:13] cmars: were you on the latest maltese-falcon when you saw it fail ^^ ? [01:13] axw_: it failed for me when casey pinged me, but i think stuff may have landed since [01:13] i'll retry [01:13] in bit [01:13] wallyworld: ok, thanks [01:25] axw_, yes, i'll confirm the revno in just a minute [01:25] cmars: thanks [01:28] axw_, yep, still getting a fail in TestUniterUpgradeConflicts at 6425ee2188 [01:29] cmars: is it intermittent? I've been running the test in a loop... :/ [01:29] axw_, it's as if the resolver doesn't get the unit state change between waitHooks & waitUnitAgent. very repeatable for me [01:30] i haven't seen it pass at all today [01:30] hrm [01:30] running with go1.2.2 (was using 1.5 but got distracted by map ordering bugs, which i've set aside for later) [01:31] I am using 1.4.2... I'll try that [01:31] axw_, anything you'd like me to try, let me know. [01:31] cmars: will do, ta [01:38] cmars: still can't repro with 1.2.2. might be helpful if you could add some debug logging to uniter/resolver.go at the top, to print out the local and remote states, and pastebin a failure [01:40] axw_, ok. in NextOp? [01:40] yes, please [01:41] I keep on doing that while debugging, should probably just leave it in and commit it [01:43] axw_, http://paste.ubuntu.com/12211350/ [01:44] cmars: thanks [03:02] cmars: would you please try applying http://paste.ubuntu.com/12211722/, and see whether it fixes the issue? there's a race between the watcher refreshing and us clearing the in-memory resolved mode [03:07] axw_, still failing [03:08] cmars: thanks. thinko, there's race there anyway [03:14] cmars: so, current thinking: upgrade fails, becomes conflicted; agent is restarted and comes up *not* thinking it's conflicted; upgrade error is fixed, and resolved mode is set; agent proceeds to upgrade (setting the resolved mode was unnecessary for this), and because it doesn't think it was conflicted, doesn't clear the resolved mode [03:16] axw_, what stores the "conflicted" state? is that just the state of the git repo (when git used to be used)? [03:16] cmars: it's set in uniter.go when an upgrade op fails [03:24] cmars: tho it looks like verifyWaitingUpgradeError is supposed to cater for this. anyway, gotta go out for lunch, will look again later [03:25] axw_, ok cool. where is local state persisted? [03:25] i think that's the issue.. if we lose the conflicted state [05:17] waigani: if you feel inclined, could you please have a look at http://reviews.vapour.ws/r/2516/ [05:50] cmars: only some local state is persisted; conflicted is not [05:51] cmars: what would happen in practice is that the uniter would come up, attempt to upgrade again and become conflicted again (unless the problem was fixed) === akhavr1 is now known as akhavr [06:29] cmars: found it... the SetAgentStatus is failing, and its error wasn't being checked === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr [07:32] dimitern: ping. I yeasterday evening pushed http://reviews.vapour.ws/r/2504/ again. would you please take a look? [07:33] TheMue, sure, it's the next on my list :) [07:33] dimitern: great, thanks [08:09] TheMue, reviewed [08:09] dimitern: thx *click* [08:09] TheMue, I've tried to clarify the need for (bool, error) result on SupportsSpaces [08:13] dimitern: yep, I've already changed it [08:14] * TheMue is typing with one hand, phonecall :/ === akhavr1 is now known as akhavr [08:43] mattyw, just added a card: "make uniter.RunCommands goroutine-safe" [08:43] mattyw, which contains a short note that might be relevant to actions [08:43] mattyw, let me know if it's useful [08:43] s/if/whether/ [08:45] dimitern: so, phone call ended. I don't think an environs function should return a params type. the change of the standard not-support to params should be done inside the server-side API [08:58] TheMue: dimitern: dooferlad: frobware: I have a suggestion [08:58] TheMue: dimitern: dooferlad: frobware: why don't we postpone the retrospective/planning for next week [08:59] when we're face to face [08:59] so just have a normal standup today [08:59] voidspace: would be fine for me [08:59] voidspace, hmm, I'm not sure how are these two related :) [09:00] voidspace, we'll see each other f2f anyway, but frobware might be interested in how we're doing the retro/planing [09:00] dimitern: but planning is one of the things that really benefits from being face to face [09:00] voidspace, agreed [09:00] dimitern: so we can still do a retrospective [09:01] but planning is one of the things we should be doing next week *anyway* [09:01] and it seems like a good way to take advantage of being face to face [09:01] voidspace, good point about the planning [09:01] dimitern: we could do the retrospective part this morning [09:01] as there is some benefit to it being fresh in our minds [09:02] but leave planning and estimation for face to face [09:03] frobware: standup? [09:03] voidspace, yes, let's see what we want to do and when. :) [09:04] frobware: we're all in standup - there seems to be consensus that doing the retrospective now is good, but leave planning and estimation until next week [09:04] voidspace, hmm. HO's tells me I'm in the hangout. [09:04] frobware: https://plus.google.com/hangouts/_/canonical.com/sapphire [09:05] frobware: are you logged in with the right google account? I've made that mistake before and it's put me in an empty hangout [09:05] ah, hi [09:05] voidspace, yep, that was it. ;) === akhavr1 is now known as akhavr [10:22] voidspace, TheMue, dooferlad, guys, since we have a 1.25 branch now, just a reminder to target your PRs against master and then backport them to 1.25 [10:23] (or vice versa - doesn't matter as long as there is a card for both and they're both done) [10:23] dimitern: thanks [10:28] * dimitern will be back in ~1h [10:32] dimitern: http://pastebin.ubuntu.com/12213276/ [10:33] dooferlad, I suspect these are due to the removal of assignPrivateIPAddress [10:33] dimitern: it is in export_test.go [10:33] dooferlad, even if you put it in export_test, in the code where it's used you need a var [10:33] dimitern: same package [10:34] dooferlad, you can't patch a func [10:34] ah [10:35] dimitern: spot on [10:35] dimitern: why not just change the function name then? [10:35] dooferlad, :) cheers [10:36] dimitern: nevermind [10:36] dimitern: because you can't patch a func [10:36] heh [10:36] dooferlad, yeah [10:36] dooferlad, so if you do var assignPrivateIPAddress = func(...) { .. }, then you can add var AssignPrivateIPAddress = &assign.. in export_test [10:37] ok, now I'm really away :) [11:24] dimitern: hey, you got a sec to take a look at this https://github.com/go-goose/goose/pull/15 [11:24] dimitern: it'll land in "liberty" branch, but would like to get some feedback from you === akhavr1 is now known as akhavr [11:49] urulama, sure, looking [12:27] sinzui, mgz_: is this a known failure? http://juju-ci.vapour.ws:8080/job/github-merge-juju-testing/14/console [12:38] urulama, reviewed [12:43] dimitern: thanks. not sure that roles are part of v3 ... might have missed it though [12:44] urulama, it appears so, according to the official API docs [12:44] dimitern: ah, right, doman + role name is globally unique across all domains [12:45] urulama, yeah, and as commented, in all cases where either ID or Name can be used, we should support both I think, if it's not a lot more work ofc [13:03] bogdanteleaga: While I am not familiar with the faillures for this job, I would still retry it because mgo_test in juju is a common cause of intermittent faillures [13:04] sinzui, bogdanteleaga, I was looking at this - it seems the failure only happened after the changes in the "testfix" branch [13:06] dimitern, yes, I did notice that but I cannot reproduce it locally [13:06] i've code a PR up for review here which will enable environment providers to generate the boilerplate YAML automatically from the environment schema. reviews appreciated: https://github.com/juju/environschema/pull/6 [13:06] bogdanteleaga, different go versions and/or arch/os ? [13:06] mgz_: this is the kind of thing you were alluding to, i think [13:06] dimitern, all it seems to do for mongo is add one extra mongo path [13:07] dimitern, 1.2.1 amd64 on trusty [13:07] dimitern, I think that's what the box is using [13:07] bogdanteleaga, yeah, that change seemed innocent enough to me, but .. well [13:08] dimitern, it is weird because I ran them about 10 times locally and I got no failure [13:08] dimitern, while it failed 3 times consecutively on the ci [13:08] sinzui, can we tweak that job to run with TEST_LOGGING_CONFIG='=TRACE' ? [13:09] sinzui, temporarily of course [13:09] bogdanteleaga, better logging will help - when it fails it seems to take ~1m each time [13:10] dimitern, sinzui, tried adding a mongod executable on the new path just in case [13:10] doesn't seem to change anything [13:11] what's more likely to be causing it is if JUJU_MONGOD is set in the job environ I think [13:13] yeah, but then that one becomes the first one and nothing should change [13:15] yeah.. something else is in play [13:24] I should really remember to take my own advice [13:59] katco: are we starting at 10 or 10:30? [13:59] wwitzel3: 10 [14:02] ericsnow: natefinch: stand up [14:05] someone want to volunteer to back ou the last change on master to unblock? [14:05] see bug 1489896 [14:05] Bug #1489896: Juju cannot upgrade to 1.26-alpha1

[14:05] Bug #1489896 opened: Juju cannot upgrade to 1.26-alpha1

[14:14] I suggest it should be OCR job is no one else steps up [14:17] Bug #1489896 changed: Juju cannot upgrade to 1.26-alpha1

[14:23] Bug #1480310 changed: systemctl link request failed for service FOO: Unit name FOO is not valid.

[14:23] Bug #1489896 opened: Juju cannot upgrade to 1.26-alpha1

=== martijn is now known as Guest70499 [15:32] fwereade, ping? [15:32] mattyw, pong [15:32] fwereade, hey hey, would you have 5 minutes to talk about the action pr? [15:32] mattyw, oops, just saw mail [15:33] mattyw, sure; and the end result of that retry command iis just what I wanted, yeah [15:33] fwereade, I'm going to be in chicago next week so wanted to chat before I end up in an awkward timezone [15:33] mattyw, good idea, thanks [15:33] fwereade, https://plus.google.com/hangouts/_/gtdt43qnnxyz7gcbbdn5clz4u4a?pqs=1&hl=en&authuser=0 [16:46] OCR or anyone else: review please to unblock master: http://reviews.vapour.ws/r/2523/ [17:01] mgz: is that just a straight up revert? [17:02] natefinch: yes [17:02] natefinch: compare with http://reviews.vapour.ws/r/2250/ [17:06] right, EOW [17:06] bye all [17:06] see some of you in London next week [17:06] mgz: ship it [17:09] thanks natefinch.. i lacked context on that one, would have been a good part of my afternoon to review :) [17:11] cmars: it was just a revert, so all I did was make sure it looked pretty much like the prior commit. [17:12] ah, right. first thing I saw was the size of the diff === akhavr1 is now known as akhavr [18:31] natefinch: in moonstone === mwenning is now known as mwenning-rr5 [20:14] ericsnow: got some trime for a little more help? I can't figure out how to get basecommand to get the ID from the args... I keep getting empty data for some reason [20:14] natefinch: k [20:39] ericsnow: There's no destroy in the API.. how is destroy different than untrack? [20:39] natefinch: destroy on the plugin (I mispoke) [20:39] oh ok [21:01] ericsnow, katco: landing that 3 pointer now... just waiting for the landing bot to take it. [21:01] natefinch: yay! good work! :D [21:01] natefinch: sweet [21:03] gotta run, but I'll pop back in to double check it really landed for true === natefinch is now known as natefinch-afk [21:47] ericsnow, katco: and, landed! [21:48] natefinch-afk: woohoo! [21:48] natefinch-afk: good work dude! [22:17] core, dev: Does anyone here know how to add custom cloud-config to maas provisioning....i.e. curtin_userdata preseeed or custom preseed?? === mup_ is now known as mup