[01:12] <axw_> wallyworld: I can't get TestUniterUpgradeConflicts to fail at all, and it's been passed by the landing bot...
[01:13] <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:25] <cmars> axw_, yes, i'll confirm the revno in just a minute
[01:25] <axw_> cmars: thanks
[01:28] <cmars> axw_, yep, still getting a fail in TestUniterUpgradeConflicts at 6425ee2188
[01:29] <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:30] <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:31] <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:38] <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:40] <cmars> axw_, ok. in NextOp?
[01:40] <axw_> yes, please
[01:41] <axw_> I keep on doing that while debugging, should probably just leave it in and commit it
[01:43] <cmars> axw_, http://paste.ubuntu.com/12211350/
[01:44] <axw_> cmars: thanks
[03:02] <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:07] <cmars> axw_, still failing
[03:08] <axw_> cmars: thanks. thinko, there's race there anyway
[03:14] <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:16] <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:24] <axw_> cmars: tho it looks like verifyWaitingUpgradeError is supposed to cater for this. anyway, gotta go out for lunch, will look again later
[03:25] <cmars> axw_, ok cool. where is local state persisted?
[03:25] <cmars> i think that's the issue.. if we lose the conflicted state
[05:17] <menn0> waigani: if you feel inclined, could you please have a look at http://reviews.vapour.ws/r/2516/
[05:50] <axw_> cmars: only some local state is persisted; conflicted is not
[05:51] <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)
[06:29] <axw_> cmars: found it... the SetAgentStatus is failing, and its error wasn't being checked
[07:32] <TheMue> dimitern: ping. I yeasterday evening pushed http://reviews.vapour.ws/r/2504/ again. would you please take a look?
[07:33] <dimitern> TheMue, sure, it's the next on my list :)
[07:33] <TheMue> dimitern: great, thanks
[08:09] <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:13] <TheMue> dimitern: yep, I've already changed it
[08:14]  * TheMue is typing with one hand, phonecall :/
[08:43] <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:45] <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:58] <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:59] <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 :)
[09:00] <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:01] <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:02] <voidspace> but leave planning and estimation for face to face
[09:03] <voidspace> frobware: standup?
[09:03] <frobware> voidspace, yes, let's see what we want to do and when. :)
[09:04] <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:05] <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. ;)
[10:22] <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:23] <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:28]  * dimitern will be back in ~1h
[10:32] <dooferlad> dimitern: http://pastebin.ubuntu.com/12213276/
[10:33] <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:34] <dimitern> dooferlad, you can't patch a func
[10:34] <dooferlad> ah
[10:35] <dooferlad> dimitern: spot on
[10:35] <dooferlad> dimitern: why not just change the function name then?
[10:35] <dimitern> dooferlad,  :) cheers
[10:36] <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:37] <dimitern> ok, now I'm really away :)
[11:24] <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:49] <dimitern> urulama, sure, looking
[12:27] <bogdanteleaga> sinzui, mgz_: is this a known failure? http://juju-ci.vapour.ws:8080/job/github-merge-juju-testing/14/console
[12:38] <dimitern> urulama, reviewed
[12:43] <urulama> dimitern: thanks. not sure that roles are part of v3 ... might have missed it though
[12:44] <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:45] <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
[13:03] <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:04] <dimitern> sinzui, bogdanteleaga, I was looking at this - it seems the failure only happened after the changes in the "testfix" branch
[13:06] <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:07] <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:08] <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:09] <dimitern> sinzui, temporarily of course
[13:09] <dimitern> bogdanteleaga, better logging will help - when it fails it seems to take ~1m each time
[13:10] <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:11] <dimitern> what's more likely to be causing it is if JUJU_MONGOD is set in the job environ I think
[13:13] <bogdanteleaga> yeah, but then that one becomes the first one and nothing should change
[13:15] <dimitern> yeah.. something else is in play
[13:24] <natefinch> I should really remember to take my own advice
[13:59] <wwitzel3> katco: are we starting at 10 or 10:30?
[13:59] <katco> wwitzel3: 10
[14:02] <katco> ericsnow: natefinch: stand up
[14:05] <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:14] <mgz_> I suggest it should be OCR job is no one else steps up
[14:17] <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:23] <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>
[15:32] <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:33] <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
[16:46] <mgz> OCR or anyone else: review please to unblock master: http://reviews.vapour.ws/r/2523/
[17:01] <natefinch> mgz: is that just a straight up revert?
[17:02] <mgz> natefinch: yes
[17:02] <mgz> natefinch: compare with http://reviews.vapour.ws/r/2250/
[17:06] <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:09] <cmars> thanks natefinch.. i lacked context on that one, would have been a good part of my afternoon to review :)
[17:11] <natefinch> cmars: it was just a revert, so all I did was make sure it looked pretty much like the prior commit.
[17:12] <cmars> ah, right. first thing I saw was the size of the diff
[18:31] <ericsnow> natefinch: in moonstone
[20:14] <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:39] <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
[21:01] <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:03] <natefinch> gotta run, but I'll pop back in to double check it really landed for true
[21:47] <natefinch-afk> ericsnow, katco: and, landed!
[21:48] <katco> natefinch-afk: woohoo!
[21:48] <katco> natefinch-afk: good work dude!
[22:17] <bdx> core, dev: Does anyone here know how to add custom cloud-config to maas provisioning....i.e. curtin_userdata preseeed or custom preseed??