axw_ | wallyworld: I can't get TestUniterUpgradeConflicts to fail at all, and it's been passed by the landing bot... | 01:12 |
---|---|---|
axw_ | cmars: were you on the latest maltese-falcon when you saw it fail ^^ ? | 01:13 |
wallyworld | axw_: it failed for me when casey pinged me, but i think stuff may have landed since | 01:13 |
wallyworld | i'll retry | 01:13 |
wallyworld | in bit | 01:13 |
axw_ | wallyworld: ok, thanks | 01:13 |
cmars | axw_, yes, i'll confirm the revno in just a minute | 01:25 |
axw_ | cmars: thanks | 01:25 |
cmars | axw_, yep, still getting a fail in TestUniterUpgradeConflicts at 6425ee2188 | 01:28 |
axw_ | cmars: is it intermittent? I've been running the test in a loop... :/ | 01:29 |
cmars | axw_, it's as if the resolver doesn't get the unit state change between waitHooks & waitUnitAgent. very repeatable for me | 01:29 |
cmars | i haven't seen it pass at all today | 01:30 |
axw_ | hrm | 01:30 |
cmars | running with go1.2.2 (was using 1.5 but got distracted by map ordering bugs, which i've set aside for later) | 01:30 |
axw_ | I am using 1.4.2... I'll try that | 01:31 |
cmars | axw_, anything you'd like me to try, let me know. | 01:31 |
axw_ | cmars: will do, ta | 01:31 |
axw_ | 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:38 |
cmars | axw_, ok. in NextOp? | 01:40 |
axw_ | yes, please | 01:40 |
axw_ | I keep on doing that while debugging, should probably just leave it in and commit it | 01:41 |
cmars | axw_, http://paste.ubuntu.com/12211350/ | 01:43 |
axw_ | cmars: thanks | 01:44 |
axw_ | 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:02 |
cmars | axw_, still failing | 03:07 |
axw_ | cmars: thanks. thinko, there's race there anyway | 03:08 |
axw_ | 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:14 |
cmars | axw_, what stores the "conflicted" state? is that just the state of the git repo (when git used to be used)? | 03:16 |
axw_ | cmars: it's set in uniter.go when an upgrade op fails | 03:16 |
axw_ | cmars: tho it looks like verifyWaitingUpgradeError is supposed to cater for this. anyway, gotta go out for lunch, will look again later | 03:24 |
cmars | axw_, ok cool. where is local state persisted? | 03:25 |
cmars | i think that's the issue.. if we lose the conflicted state | 03:25 |
menn0 | waigani: if you feel inclined, could you please have a look at http://reviews.vapour.ws/r/2516/ | 05:17 |
axw_ | cmars: only some local state is persisted; conflicted is not | 05:50 |
axw_ | 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) | 05:51 |
=== akhavr1 is now known as akhavr | ||
axw_ | cmars: found it... the SetAgentStatus is failing, and its error wasn't being checked | 06:29 |
=== akhavr1 is now known as akhavr | ||
=== akhavr1 is now known as akhavr | ||
TheMue | dimitern: ping. I yeasterday evening pushed http://reviews.vapour.ws/r/2504/ again. would you please take a look? | 07:32 |
dimitern | TheMue, sure, it's the next on my list :) | 07:33 |
TheMue | dimitern: great, thanks | 07:33 |
dimitern | TheMue, reviewed | 08:09 |
TheMue | dimitern: thx *click* | 08:09 |
dimitern | TheMue, I've tried to clarify the need for (bool, error) result on SupportsSpaces | 08:09 |
TheMue | dimitern: yep, I've already changed it | 08:13 |
* TheMue is typing with one hand, phonecall :/ | 08:14 | |
=== akhavr1 is now known as akhavr | ||
fwereade | mattyw, just added a card: "make uniter.RunCommands goroutine-safe" | 08:43 |
fwereade | mattyw, which contains a short note that might be relevant to actions | 08:43 |
fwereade | mattyw, let me know if it's useful | 08:43 |
fwereade | s/if/whether/ | 08:43 |
TheMue | 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:45 |
voidspace | TheMue: dimitern: dooferlad: frobware: I have a suggestion | 08:58 |
voidspace | TheMue: dimitern: dooferlad: frobware: why don't we postpone the retrospective/planning for next week | 08:58 |
voidspace | when we're face to face | 08:59 |
voidspace | so just have a normal standup today | 08:59 |
TheMue | voidspace: would be fine for me | 08:59 |
dimitern | voidspace, hmm, I'm not sure how are these two related :) | 08:59 |
dimitern | voidspace, we'll see each other f2f anyway, but frobware might be interested in how we're doing the retro/planing | 09:00 |
voidspace | dimitern: but planning is one of the things that really benefits from being face to face | 09:00 |
frobware | voidspace, agreed | 09:00 |
voidspace | dimitern: so we can still do a retrospective | 09:00 |
voidspace | but planning is one of the things we should be doing next week *anyway* | 09:01 |
voidspace | and it seems like a good way to take advantage of being face to face | 09:01 |
dimitern | voidspace, good point about the planning | 09:01 |
voidspace | dimitern: we could do the retrospective part this morning | 09:01 |
voidspace | as there is some benefit to it being fresh in our minds | 09:01 |
voidspace | but leave planning and estimation for face to face | 09:02 |
voidspace | frobware: standup? | 09:03 |
frobware | voidspace, yes, let's see what we want to do and when. :) | 09:03 |
voidspace | 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 |
frobware | voidspace, hmm. HO's tells me I'm in the hangout. | 09:04 |
dooferlad | frobware: https://plus.google.com/hangouts/_/canonical.com/sapphire | 09:04 |
voidspace | 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 |
voidspace | ah, hi | 09:05 |
frobware | voidspace, yep, that was it. ;) | 09:05 |
=== akhavr1 is now known as akhavr | ||
dimitern | 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:22 |
dimitern | (or vice versa - doesn't matter as long as there is a card for both and they're both done) | 10:23 |
voidspace | dimitern: thanks | 10:23 |
* dimitern will be back in ~1h | 10:28 | |
dooferlad | dimitern: http://pastebin.ubuntu.com/12213276/ | 10:32 |
dimitern | dooferlad, I suspect these are due to the removal of assignPrivateIPAddress | 10:33 |
dooferlad | dimitern: it is in export_test.go | 10:33 |
dimitern | dooferlad, even if you put it in export_test, in the code where it's used you need a var | 10:33 |
dooferlad | dimitern: same package | 10:33 |
dimitern | dooferlad, you can't patch a func | 10:34 |
dooferlad | ah | 10:34 |
dooferlad | dimitern: spot on | 10:35 |
dooferlad | dimitern: why not just change the function name then? | 10:35 |
dimitern | dooferlad, :) cheers | 10:35 |
dooferlad | dimitern: nevermind | 10:36 |
dooferlad | dimitern: because you can't patch a func | 10:36 |
dooferlad | heh | 10:36 |
dimitern | dooferlad, yeah | 10:36 |
dimitern | dooferlad, so if you do var assignPrivateIPAddress = func(...) { .. }, then you can add var AssignPrivateIPAddress = &assign.. in export_test | 10:36 |
dimitern | ok, now I'm really away :) | 10:37 |
urulama | dimitern: hey, you got a sec to take a look at this https://github.com/go-goose/goose/pull/15 | 11:24 |
urulama | dimitern: it'll land in "liberty" branch, but would like to get some feedback from you | 11:24 |
=== akhavr1 is now known as akhavr | ||
dimitern | urulama, sure, looking | 11:49 |
bogdanteleaga | sinzui, mgz_: is this a known failure? http://juju-ci.vapour.ws:8080/job/github-merge-juju-testing/14/console | 12:27 |
dimitern | urulama, reviewed | 12:38 |
urulama | dimitern: thanks. not sure that roles are part of v3 ... might have missed it though | 12:43 |
dimitern | urulama, it appears so, according to the official API docs | 12:44 |
urulama | dimitern: ah, right, doman + role name is globally unique across all domains | 12:44 |
dimitern | 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 | 12:45 |
sinzui | 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:03 |
dimitern | sinzui, bogdanteleaga, I was looking at this - it seems the failure only happened after the changes in the "testfix" branch | 13:04 |
bogdanteleaga | dimitern, yes, I did notice that but I cannot reproduce it locally | 13:06 |
rogpeppe | 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 |
dimitern | bogdanteleaga, different go versions and/or arch/os ? | 13:06 |
rogpeppe | mgz_: this is the kind of thing you were alluding to, i think | 13:06 |
bogdanteleaga | dimitern, all it seems to do for mongo is add one extra mongo path | 13:06 |
bogdanteleaga | dimitern, 1.2.1 amd64 on trusty | 13:07 |
bogdanteleaga | dimitern, I think that's what the box is using | 13:07 |
dimitern | bogdanteleaga, yeah, that change seemed innocent enough to me, but .. well | 13:07 |
bogdanteleaga | dimitern, it is weird because I ran them about 10 times locally and I got no failure | 13:08 |
bogdanteleaga | dimitern, while it failed 3 times consecutively on the ci | 13:08 |
dimitern | sinzui, can we tweak that job to run with TEST_LOGGING_CONFIG='<root>=TRACE' ? | 13:08 |
dimitern | sinzui, temporarily of course | 13:09 |
dimitern | bogdanteleaga, better logging will help - when it fails it seems to take ~1m each time | 13:09 |
bogdanteleaga | dimitern, sinzui, tried adding a mongod executable on the new path just in case | 13:10 |
bogdanteleaga | doesn't seem to change anything | 13:10 |
dimitern | what's more likely to be causing it is if JUJU_MONGOD is set in the job environ I think | 13:11 |
bogdanteleaga | yeah, but then that one becomes the first one and nothing should change | 13:13 |
dimitern | yeah.. something else is in play | 13:15 |
natefinch | I should really remember to take my own advice | 13:24 |
wwitzel3 | katco: are we starting at 10 or 10:30? | 13:59 |
katco | wwitzel3: 10 | 13:59 |
katco | ericsnow: natefinch: stand up | 14:02 |
mgz_ | someone want to volunteer to back ou the last change on master to unblock? | 14:05 |
mgz_ | see bug 1489896 | 14:05 |
mup | Bug #1489896: Juju cannot upgrade to 1.26-alpha1 <blocker> <ci> <regression> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1489896> | 14:05 |
mup | Bug #1489896 opened: Juju cannot upgrade to 1.26-alpha1 <blocker> <ci> <regression> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1489896> | 14:05 |
mgz_ | I suggest it should be OCR job is no one else steps up | 14:14 |
mup | Bug #1489896 changed: Juju cannot upgrade to 1.26-alpha1 <blocker> <ci> <regression> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1489896> | 14:17 |
mup | Bug #1480310 changed: systemctl link request failed for service FOO: Unit name FOO is not valid. <blocker> <ci> <systemd> <wily> <juju-core:Fix Released> <systemd (Ubuntu):Fix Released by pitti> <https://launchpad.net/bugs/1480310> | 14:23 |
mup | Bug #1489896 opened: Juju cannot upgrade to 1.26-alpha1 <blocker> <ci> <regression> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1489896> | 14:23 |
=== martijn is now known as Guest70499 | ||
mattyw | fwereade, ping? | 15:32 |
fwereade | mattyw, pong | 15:32 |
mattyw | fwereade, hey hey, would you have 5 minutes to talk about the action pr? | 15:32 |
fwereade | mattyw, oops, just saw mail | 15:32 |
fwereade | mattyw, sure; and the end result of that retry command iis just what I wanted, yeah | 15:33 |
mattyw | fwereade, I'm going to be in chicago next week so wanted to chat before I end up in an awkward timezone | 15:33 |
fwereade | mattyw, good idea, thanks | 15:33 |
mattyw | fwereade, https://plus.google.com/hangouts/_/gtdt43qnnxyz7gcbbdn5clz4u4a?pqs=1&hl=en&authuser=0 | 15:33 |
mgz | OCR or anyone else: review please to unblock master: http://reviews.vapour.ws/r/2523/ | 16:46 |
natefinch | mgz: is that just a straight up revert? | 17:01 |
mgz | natefinch: yes | 17:02 |
mgz | natefinch: compare with http://reviews.vapour.ws/r/2250/ | 17:02 |
voidspace | right, EOW | 17:06 |
voidspace | bye all | 17:06 |
voidspace | see some of you in London next week | 17:06 |
natefinch | mgz: ship it | 17:06 |
cmars | thanks natefinch.. i lacked context on that one, would have been a good part of my afternoon to review :) | 17:09 |
natefinch | cmars: it was just a revert, so all I did was make sure it looked pretty much like the prior commit. | 17:11 |
cmars | ah, right. first thing I saw was the size of the diff | 17:12 |
=== akhavr1 is now known as akhavr | ||
ericsnow | natefinch: in moonstone | 18:31 |
=== mwenning is now known as mwenning-rr5 | ||
natefinch | 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 |
ericsnow | natefinch: k | 20:14 |
natefinch | ericsnow: There's no destroy in the API.. how is destroy different than untrack? | 20:39 |
ericsnow | natefinch: destroy on the plugin (I mispoke) | 20:39 |
natefinch | oh ok | 20:39 |
natefinch | ericsnow, katco: landing that 3 pointer now... just waiting for the landing bot to take it. | 21:01 |
katco | natefinch: yay! good work! :D | 21:01 |
ericsnow | natefinch: sweet | 21:01 |
natefinch | gotta run, but I'll pop back in to double check it really landed for true | 21:03 |
=== natefinch is now known as natefinch-afk | ||
natefinch-afk | ericsnow, katco: and, landed! | 21:47 |
katco | natefinch-afk: woohoo! | 21:48 |
katco | natefinch-afk: good work dude! | 21:48 |
bdx | core, dev: Does anyone here know how to add custom cloud-config to maas provisioning....i.e. curtin_userdata preseeed or custom preseed?? | 22:17 |
=== mup_ is now known as mup |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!