/srv/irclogs.ubuntu.com/2015/08/28/#juju-dev.txt

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
wallyworldaxw_: it failed for me when casey pinged me, but i think stuff may have landed since01:13
wallyworldi'll retry01:13
wallyworldin  bit01:13
axw_wallyworld: ok, thanks01:13
cmarsaxw_, yes, i'll confirm the revno in just a minute01:25
axw_cmars: thanks01:25
cmarsaxw_, yep, still getting a fail in TestUniterUpgradeConflicts at 6425ee218801:28
axw_cmars: is it intermittent? I've been running the test in a loop... :/01:29
cmarsaxw_, it's as if the resolver doesn't get the unit state change between waitHooks & waitUnitAgent. very repeatable for me01:29
cmarsi haven't seen it pass at all today01:30
axw_hrm01:30
cmarsrunning 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 that01:31
cmarsaxw_, anything you'd like me to try, let me know.01:31
axw_cmars: will do, ta01: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 failure01:38
cmarsaxw_, ok. in NextOp?01:40
axw_yes, please01:40
axw_I keep on doing that while debugging, should probably just leave it in and commit it01:41
cmarsaxw_, http://paste.ubuntu.com/12211350/01:43
axw_cmars: thanks01: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 mode03:02
cmarsaxw_, still failing03:07
axw_cmars: thanks. thinko, there's race there anyway03: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 mode03:14
cmarsaxw_, 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 fails03:16
axw_cmars: tho it looks like verifyWaitingUpgradeError is supposed to cater for this. anyway, gotta go out for lunch, will look again later03:24
cmarsaxw_, ok cool. where is local state persisted?03:25
cmarsi think that's the issue.. if we lose the conflicted state03:25
menn0waigani: 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 not05: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 checked06:29
=== akhavr1 is now known as akhavr
=== akhavr1 is now known as akhavr
TheMuedimitern: ping. I yeasterday evening pushed http://reviews.vapour.ws/r/2504/ again. would you please take a look?07:32
dimiternTheMue, sure, it's the next on my list :)07:33
TheMuedimitern: great, thanks07:33
dimiternTheMue, reviewed08:09
TheMuedimitern: thx *click*08:09
dimiternTheMue, I've tried to clarify the need for (bool, error) result on SupportsSpaces08:09
TheMuedimitern: yep, I've already changed it08:13
* TheMue is typing with one hand, phonecall :/08:14
=== akhavr1 is now known as akhavr
fwereademattyw, just added a card: "make uniter.RunCommands goroutine-safe"08:43
fwereademattyw, which contains a short note that might be relevant to actions08:43
fwereademattyw, let me know if it's useful08:43
fwereades/if/whether/08:43
TheMuedimitern: 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 API08:45
voidspaceTheMue: dimitern: dooferlad: frobware: I have a suggestion08:58
voidspaceTheMue: dimitern: dooferlad: frobware: why don't we postpone the retrospective/planning for next week08:58
voidspacewhen we're face to face08:59
voidspaceso just have a normal standup today08:59
TheMuevoidspace: would be fine for me08:59
dimiternvoidspace, hmm, I'm not sure how are these two related :)08:59
dimiternvoidspace, we'll see each other f2f anyway, but frobware might be interested in how we're doing the retro/planing09:00
voidspacedimitern: but planning is one of the things that really benefits from being face to face09:00
frobwarevoidspace, agreed09:00
voidspacedimitern: so we can still do a retrospective09:00
voidspacebut planning is one of the things we should be doing next week *anyway*09:01
voidspaceand it seems like a good way to take advantage of being face to face09:01
dimiternvoidspace, good point about the planning09:01
voidspacedimitern: we could do the retrospective part this morning09:01
voidspaceas there is some benefit to it being fresh in our minds09:01
voidspacebut leave planning and estimation for face to face09:02
voidspacefrobware: standup?09:03
frobwarevoidspace, yes, let's see what we want to do and when. :)09:03
voidspacefrobware: we're all in standup - there seems to be consensus that doing the retrospective now is good, but leave planning and estimation until next week09:04
frobwarevoidspace, hmm. HO's tells me I'm in the hangout.09:04
dooferladfrobware: https://plus.google.com/hangouts/_/canonical.com/sapphire09:04
voidspacefrobware: are you logged in with the right google account? I've made that mistake before and it's put me in an empty hangout09:05
voidspaceah, hi09:05
frobwarevoidspace, yep, that was it. ;)09:05
=== akhavr1 is now known as akhavr
dimiternvoidspace, 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.2510:22
dimitern(or vice versa - doesn't matter as long as there is a card for both and they're both done)10:23
voidspacedimitern: thanks10:23
* dimitern will be back in ~1h10:28
dooferladdimitern: http://pastebin.ubuntu.com/12213276/10:32
dimiterndooferlad, I suspect these are due to the removal of assignPrivateIPAddress10:33
dooferladdimitern: it is in export_test.go10:33
dimiterndooferlad, even if you put it in export_test, in the code where it's used you need a var10:33
dooferladdimitern: same package10:33
dimiterndooferlad, you can't patch a func10:34
dooferladah10:34
dooferladdimitern: spot on10:35
dooferladdimitern: why not just change the function name then?10:35
dimiterndooferlad,  :) cheers10:35
dooferladdimitern: nevermind10:36
dooferladdimitern: because you can't patch a func10:36
dooferladheh10:36
dimiterndooferlad, yeah10:36
dimiterndooferlad, so if you do var assignPrivateIPAddress = func(...) { .. }, then you can add var AssignPrivateIPAddress = &assign.. in export_test10:36
dimiternok, now I'm really away :)10:37
urulamadimitern: hey, you got a sec to take a look at this https://github.com/go-goose/goose/pull/1511:24
urulamadimitern: it'll land in "liberty" branch, but would like to get some feedback from you11:24
=== akhavr1 is now known as akhavr
dimiternurulama, sure, looking11:49
bogdanteleagasinzui, mgz_: is this a known failure? http://juju-ci.vapour.ws:8080/job/github-merge-juju-testing/14/console12:27
dimiternurulama, reviewed12:38
urulamadimitern: thanks. not sure that roles are part of v3 ... might have missed it though12:43
dimiternurulama, it appears so, according to the official API docs12:44
urulamadimitern: ah, right, doman + role name is globally unique across all domains12:44
dimiternurulama, 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 ofc12:45
sinzuibogdanteleaga: 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 faillures13:03
dimiternsinzui, bogdanteleaga, I was looking at this - it seems the failure only happened after the changes in the "testfix" branch13:04
bogdanteleagadimitern, yes, I did notice that but I cannot reproduce it locally13:06
rogpeppei'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/613:06
dimiternbogdanteleaga, different go versions and/or arch/os ?13:06
rogpeppemgz_: this is the kind of thing you were alluding to, i think13:06
bogdanteleagadimitern, all it seems to do for mongo is add one extra mongo path13:06
bogdanteleagadimitern, 1.2.1 amd64 on trusty13:07
bogdanteleagadimitern, I think that's what the box is using13:07
dimiternbogdanteleaga, yeah, that change seemed innocent enough to me, but .. well13:07
bogdanteleagadimitern, it is weird because I ran them about 10 times locally and I got no failure13:08
bogdanteleagadimitern, while it failed 3 times consecutively on the ci13:08
dimiternsinzui, can we tweak that job to run with TEST_LOGGING_CONFIG='<root>=TRACE' ?13:08
dimiternsinzui, temporarily of course13:09
dimiternbogdanteleaga, better logging will help - when it fails it seems to take ~1m each time13:09
bogdanteleagadimitern, sinzui, tried adding a mongod executable on the new path just in case13:10
bogdanteleagadoesn't seem to change anything13:10
dimiternwhat's more likely to be causing it is if JUJU_MONGOD is set in the job environ I think13:11
bogdanteleagayeah, but then that one becomes the first one and nothing should change13:13
dimiternyeah.. something else is in play13:15
natefinchI should really remember to take my own advice13:24
wwitzel3katco: are we starting at 10 or 10:30?13:59
katcowwitzel3: 1013:59
katcoericsnow: natefinch: stand up14:02
mgz_someone want to volunteer to back ou the last change on master to unblock?14:05
mgz_see bug 148989614:05
mupBug #1489896: Juju cannot upgrade to 1.26-alpha1 <blocker> <ci> <regression> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1489896>14:05
mupBug #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 up14:14
mupBug #1489896 changed: Juju cannot upgrade to 1.26-alpha1 <blocker> <ci> <regression> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1489896>14:17
mupBug #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
mupBug #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
mattywfwereade, ping?15:32
fwereademattyw, pong15:32
mattywfwereade, hey hey, would you have 5 minutes to talk about the action pr?15:32
fwereademattyw, oops, just saw mail15:32
fwereademattyw, sure; and the end result of that retry command iis just what I wanted, yeah15:33
mattywfwereade, I'm going to be in chicago next week so wanted to chat before I end up in an awkward timezone15:33
fwereademattyw, good idea, thanks15:33
mattywfwereade, https://plus.google.com/hangouts/_/gtdt43qnnxyz7gcbbdn5clz4u4a?pqs=1&hl=en&authuser=015:33
mgzOCR or anyone else: review please to unblock master: http://reviews.vapour.ws/r/2523/16:46
natefinchmgz: is that just a straight up revert?17:01
mgznatefinch: yes17:02
mgznatefinch: compare with http://reviews.vapour.ws/r/2250/17:02
voidspaceright, EOW17:06
voidspacebye all17:06
voidspacesee some of you in London next week17:06
natefinchmgz: ship it17:06
cmarsthanks natefinch.. i lacked context on that one, would have been a good part of my afternoon to review :)17:09
natefinchcmars: it was just a revert, so all I did was make sure it looked pretty much like the prior commit.17:11
cmarsah, right. first thing I saw was the size of the diff17:12
=== akhavr1 is now known as akhavr
ericsnownatefinch: in moonstone18:31
=== mwenning is now known as mwenning-rr5
natefinchericsnow: 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 reason20:14
ericsnownatefinch: k20:14
natefinchericsnow: There's no destroy in the API.. how is destroy different than untrack?20:39
ericsnownatefinch: destroy on the plugin (I mispoke)20:39
natefinchoh ok20:39
natefinchericsnow, katco: landing that 3 pointer now... just waiting for the landing bot to take it.21:01
katconatefinch: yay! good work! :D21:01
ericsnownatefinch: sweet21:01
natefinchgotta run, but I'll pop back in to double check it really landed for true21:03
=== natefinch is now known as natefinch-afk
natefinch-afkericsnow, katco: and, landed!21:47
katconatefinch-afk: woohoo!21:48
katconatefinch-afk: good work dude!21:48
bdxcore, 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!