[01:47] <axw> wallyworld: we didn't do planning.. I'm thinking 8 for the force-destroy card, because I think I'm going to have to go and implement ListVolumes/ListFilesystems as well
[01:47] <wallyworld> axw: or even break it up
[01:47] <wallyworld> a separate card for ListX
[01:47] <axw> wallyworld: well I'm not sure if that's how it'll work yet. I'll break it up when I have a better idea
[01:48] <wallyworld> ok
[01:48] <axw> wallyworld: will set 8 for now and then break up later, ok?
[01:48] <wallyworld> sure
[01:48] <wallyworld> we'll do more tonight
[01:50]  * thumper is running tests in windows and locally
[01:50] <thumper> god I hate the uniter tests
[01:54]  * thumper cries quietly as a different test fails intermittently on windows
[01:56] <mup> Bug #1476060 opened: uniter_test.go, startUpgradeError{} fails for windows <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1476060>
[02:06] <thumper> wallyworld: do you know much about the unit tests around "update-status"
[02:06] <thumper> wallyworld: I have an intermittent failure here
[02:06] <wallyworld> test name?
[02:08] <wallyworld> thumper: ?
[02:09] <thumper> uniter_test.go: 1351
[02:09] <thumper> nope
[02:09] <thumper> not that line
[02:11] <thumper> line 1310
[02:11] <wallyworld> looking
[02:11] <thumper> test desc: 			"all relations are available to config-changed on bounce, even if state dir is missing",
[02:11] <thumper> it blocks waiting for hooks
[02:11] <wallyworld> for idle?
[02:11] <thumper> start_hooks(false) expects an "update-status" hook call
[02:12] <thumper> then on line 1340, it waits for: 			waitHooks{"update-status", "config-changed"},
[02:12] <thumper> in the logs, there is only one "update-status" hook call, not two
[02:12] <wallyworld> my line numbers are different
[02:12] <thumper> ah... yeah
[02:13] <thumper> I'm looking in a branch where I added a few lines further up
[02:13] <thumper> due to fixing another bug
[02:13] <thumper> sorry
[02:13] <wallyworld> if the next comment after the waitHooks //// Check the state dir was recreated.
[02:13] <wallyworld> is
[02:14] <wallyworld> i can't see anything immediately obvious but horatio has done all that code, reviewed by william. i'll as him to look
[02:14] <wallyworld> how often does it fail?
[02:15] <thumper> regularly now on ppc64el and windows
[02:15] <thumper> enough to be a critical blocker
[02:15] <wallyworld> but on ubuntu is ok?
[02:15] <thumper> yep
[02:15] <thumper> wonderful eh?
[02:15] <wallyworld> sigh
[02:15] <thumper> and I just fixed a different bug
[02:15] <wallyworld> in uniter?
[02:15] <thumper> well, fix is an extreme word
[02:15] <thumper> skip a test
[02:15]  * thumper is submitting now
[02:15] <wallyworld> ah :-)
[02:16] <thumper> the bug mentions a failing test
[02:16] <thumper> there were two
[02:16] <thumper> and I fixed the one this bug didn't mention
[02:16]  * thumper sighs
[02:16] <wallyworld> ok, we'll take care of this other one
[02:16] <wallyworld> maybe we need to finally gate landings on windows and ppc tests
[02:16]  * thumper nods
[02:17] <wallyworld> like we've been talking about forever
[02:17] <thumper> I have a windows vm running
[02:17] <wallyworld> ooh yuck
[02:17] <thumper> there is one thing that looked strange to me
[02:17] <thumper> replacing a real timeout value with zero
[02:18] <thumper> I'm not convinced that that time.After always works properly with that
[02:18] <thumper> seen evidence in other places
[02:18] <thumper> perhaps replace with 1 millisecond
[02:18] <thumper> rather than zero
[02:20] <thumper> wallyworld: http://reviews.vapour.ws/r/2206/diff/#
[02:20] <wallyworld> looking
[02:20]  * wallyworld forgot he was ocr
[02:21] <wallyworld> sigh
[02:21] <thumper> oh...
[02:21] <thumper> it is 1 millisecond now
[02:22] <wallyworld> thumper: i think also a mock timer was introduced
[02:22] <thumper> why do we have both?
[02:22] <wallyworld> to control the triggering of the idle event
[02:22] <thumper> 	s.PatchValue(uniter.LoopIsIdleCheckTime, 1*time.Millisecond)
[02:22] <thumper> 	s.PatchValue(uniter.EnterLoopIsIdleTime, 1*time.Millisecond)
[02:23] <thumper> the timing is different on ppc and windows
[02:23] <wallyworld> in what way?
[02:23] <thumper> hence, I'm betting this is why we are getting different numbers of calls
[02:23] <thumper> scheduler works differently on different architectures / platforms
[02:23] <wallyworld> 1 milli second is too small anyway
[02:24] <thumper> these tests aren't checking for idle
[02:24] <wallyworld> no, but update status hook depends on idle
[02:24] <thumper> just the update status
[02:24] <thumper> ah
[02:24] <thumper> poo
[02:24] <wallyworld> update status only fired when idle
[02:24]  * thumper goes to make a coffee
[02:25]  * wallyworld is jealous - coffee machine here is broken :-(
[03:48] <menn0> thumper or wallyworld: http://reviews.vapour.ws/r/2207/diff/#
[04:16] <wallyworld> menn0: +1 - did horatio's fix need to be backed out now this is handled generically? ie i guess the whole doc can be passed in now
[04:17] <wallyworld> that would be ore robust than naming the fields
[04:18] <menn0> wallyworld: that's the plan. I'm going to undo the fixes he made.
[04:18] <wallyworld> ok, ty
[04:18] <menn0> wallyworld: there's also going to be a PR with DB migrations which fix the currently incorrect records
[04:19] <wallyworld> yay
[05:18] <menn0> thumper or wallyworld: http://reviews.vapour.ws/r/2208/
[05:18] <wallyworld> looking
[05:18] <wallyworld> yay
[05:43] <thumper> poke me with a fork
[05:43] <thumper> I'm done
[05:43] <thumper> laters
[09:01] <dooferlad> TheMue: hangout?
[09:02] <TheMue> dooferlad: omw, had phone
[09:03] <dooferlad> fwereade: are you hangoutable?
[11:40] <mup> Bug #1476214 opened: --repository option for 'juju deploy' sometimes has issues with symlinked directories <juju-core:New> <https://launchpad.net/bugs/1476214>
[12:49] <tasdomas> hi
[12:50] <tasdomas> has anyone seen test failures for github.com/juju/juju/service ?
[12:50] <tasdomas> http://paste.ubuntu.com/11909054/
[12:50] <perrito666> tasdomas: yes I attributed them to my system being dirty
[12:51] <tasdomas> perrito666, ;-]
[12:51] <perrito666> tasdomas: seems that it is something else
[12:51] <perrito666> series "\" is certainly wrong
[12:52] <tasdomas> perrito666, yeah - that was my thinking too
[12:58] <dooferlad> TheMue: could you take a look at http://reviews.vapour.ws/r/2197/ when you have the time?
[12:59] <TheMue> dooferlad: will take it for you *rofl*
[13:09] <sinzui> katco: alexisb: 1.24.3 needs one commit and bless to be released. This review has "Ship It" http://reviews.vapour.ws/r/2210/, may I queue to to merge?
[13:12] <mgz> sinzui: it's not clearl which part of the fix for the bug that is...
[13:12] <sinzui> mgz: The bug lists 3 branches, that is the only one not merged.
[13:12] <mgz> okAY, MEENO ADDED TH INFO IN THE BUG
[13:13] <mgz> caaaaps
[13:13] <mgz> sinzui: landing it seems good to me, I'll queue
[13:14] <sinzui> mgz: meno also added the same comment on his other in progress bug https://launchpad.net/juju-core/+milestone/1.24.3. I think bug 1474195 is fix committed
[13:14] <mup> Bug #1474195: juju 1.24 memory leakage <cpec> <deployer> <performance> <regression> <juju-core:Triaged> <juju-core 1.24:In Progress by menno.smits> <https://launchpad.net/bugs/1474195>
[13:17] <mgz> sinzui: see uniter tests thread on juju-dev list for more fun
[13:17] <sinzui> mgz :/ I am reading the argument to merge jes-cli snd make it master
[13:23] <lazyPower> does anyone have a moment to help debug juju-db not running on a state server? I'm out of ideas as to why its failing to start up and syslog is not giving me anything helpful to go on.
[13:23] <lazyPower> lukasa in #juju would appreciate it i'm sure.
[14:01] <katco> natefinch: standup
[14:17] <katco> wwitzel3: ericsnow: natefinch: doh just remembered. i will be out over lunch. doc. appt.
[14:17] <ericsnow> fwereade: thanks for those reviews!
[14:23] <fwereade> ericsnow, yw, hope they helped
[14:24] <ericsnow> fwereade: definitely
[14:24] <fwereade> ericsnow, do you see what I mean about having details nested inside what one whight thing were model packages?
[14:24] <fwereade> s/thinng/think/
[14:24] <ericsnow> fwereade: haven't read through the reviews in detail yet :)
[14:24] <fwereade> ah god I just can't type
[14:25] <fwereade> ericsnow, let me know if anything bears further discussion :)
[14:25] <ericsnow> fwereade: will do
[14:25] <mup> Bug #1476214 changed: --repository option for 'juju deploy' sometimes has issues with symlinked directories <juju-core:New> <https://launchpad.net/bugs/1476214>
[15:25] <mup> Bug #1442149 opened: UniterSuite.TestUniterUpgradeConflicts fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1442149>
[15:41] <TheMue> dooferlad: have to swap offices in a few moments, so I'm not sure if I'll be at the network hangout
[15:41] <dooferlad> TheMue: OK, join when you can
[15:42] <TheMue> dooferlad: will do
[15:44] <dooferlad> TheMue: you merged didn't you... *slap*
[15:44] <TheMue> dooferlad: I should, shouldn't I ... ;)
[15:45] <dooferlad> TheMue: rebase! rebase!
[15:45] <dooferlad> TheMue: it is easy to fix
[15:45] <dooferlad> TheMue: just a bit annoying
[15:45] <TheMue> dooferlad: ah, the newest one, hmm, I thought I rebased
[15:46] <dooferlad> TheMue: don't worry. The best thing to do is only make changes on a branch that are related to the topic you are working on
[15:47] <dooferlad> TheMue: we can do a rebase on master as a specific task
[15:48] <TheMue> dooferlad: I do so
[15:49] <dooferlad> TheMue: odd. Oh well, merge-commit from master onto net-cli, then rebase net-cli on master works to clean things up.
[15:49] <TheMue> dooferlad: I currently don't work on net-cli
[15:57] <katco> ericsnow: wwitzel3: so the status api server has the same interesting property as state, which is to say it's difficult to abstract without embedding your type in the existing status apiserver struct
[15:58] <ericsnow> katco: lovely
[15:58] <katco> ericsnow: wwitzel3: we could begin a pattern wherein we register accessors that return either a json string or interface{}
[15:59] <katco> ericsnow: wwitzel3: returning a structured string (json) doesn't strike me as horrible, but it may be a bit different than we're doing things currently
[15:59] <katco> ericsnow: wwitzel3: we'll have to see
[16:11] <wwitzel3> katco: hrmm, I think json sounds reasonable
[16:12] <katco> wwitzel3: i do too... so we would register functions/types that get status for something and have sig func() (string, error)
[16:12] <katco> wwitzel3: and then the common apiserver stuff would iterate through those and bundle it in the result
[16:13] <katco> wwitzel3: and then the client would have to understand how to parse that
[16:13] <katco> wwitzel3: it's just a bit different than we do it now, b/c we have our RPC functionality do that bit for us
[16:14] <katco> wwitzel3: i.e. FacadeCall("FullStatus", &statusType) instead of FacadeCall("FullStatus", &jsonString)
[16:14] <wwitzel3> katco: yeah, the thing that is nice about that is then state and registered clients have an implicit contract and we aren't having to try and force things for future clients in to some interface that is likely to be different depending on the needs of the component
[16:16] <katco> wwitzel3: i don't think it solves our versioning problem, if that's what you're saying
[16:17] <katco> wwitzel3: we still have to account for combinations of client & server version
[16:17] <wwitzel3> katco: no, not versioning, it simplifies how things look when we start to add and/or refactor other things to components
[16:17] <katco> wwitzel3: ah, yes
[18:39] <sinzui> katco: Do you have a few minutes to review http://reviews.vapour.ws/r/2216/
[18:52] <alexisb> sinzui, katco is away atm
[18:52] <sinzui> thank you alexisb
[18:52] <alexisb> maybe another moonstone team member can help
[18:52] <alexisb> wwitzel3, natefinch, ericsnow ^^^
[18:53] <ericsnow> sinzui: done :)
[18:53] <sinzui> thank you ericsnow
[18:53] <natefinch> damn beat me
[18:55] <alexisb> ericsnow is lightning fast!
[19:00] <katco> alexisb: ty :)
[19:01] <alexisb> katco, thank you for keeping the team calendar up-to-date :)
[19:06] <perrito666> sinzui: hey, is there a way I can procure a ppc machine for a moment to try out some things for the uniter blocker?
[19:07] <sinzui> perrito666: I can put your key on stilson-09. You can hack on the same machine that runs the test
[19:07] <perrito666> sinzui: that would work
[19:40] <katco> ericsnow: is your state branch landed yet?
[19:40] <ericsnow> yep
[19:41] <katco> ericsnow: cool... does wwitzel3 and natefinch know so they can rebase?
[19:41] <ericsnow> katco: right now trying to land the branch with the fixes for bugs we found while trying to get the demo working
[19:41] <katco> ericsnow: ah ok. so hold off?
[19:41] <ericsnow> katco: for the moment
[19:42] <ericsnow> katco: actually, that shouldn't be a real blocker
[19:44] <wwitzel3> yeah, once those fixes land I'll be able to give another end to end run of the wordpress-wpm charm
[19:44] <wwitzel3> I cleaned up the charm and fixes up the errors I hit along the way though, so it is pretty good shape now
[19:44] <katco> wwitzel3: cool ty
[19:45] <katco> ericsnow: wwitzel3: natefinch: if anyone is interested in what i'm doing, i can pair. some interesting problems
[19:45] <wwitzel3> katco: yeah, that sounds good
[19:46] <katco> wwitzel3: cool i'll hop in moonstone
[20:36] <katco> ericsnow: hey which struct stores juju's notion of process state?
[20:37] <ericsnow> katco: in what context?
[20:37] <natefinch> ericsnow or wwitzel3: can one of you give me edit rights to the Juju Charm Workload Process Management doc? I have to tweak the juju status output, because what's there is invalid yaml :)
[20:38] <wwitzel3> natefinch: will do that now
[20:38] <katco> ericsnow: so when we run juju status, where do i go to get the new process info out of state?
[20:39] <ericsnow> katco: see State.UnitProcesses() (in state/processes.go)
[20:44] <katco> ericsnow: can you join moonstone rq?
[20:44] <ericsnow> katco: sure
[21:02] <natefinch> back later
[21:14] <thumper> sinzui: if we want ppc64el tests to pass, we NEED to increase the timeout
[21:14] <waigani> katco, ericsnow: wasn't this fix landed in 1.25: https://bugs.launchpad.net/juju-core/+bug/1468815
[21:14] <mup> Bug #1468815: Upgrade fails moving syslog config files "invalid argument" <ci> <regression> <upgrade-juju> <juju-core:Triaged> <juju-core 1.24:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1468815>
[21:14] <ericsnow> waigani: wwitzel3 is working on that
[21:14] <waigani> ericsnow: okay, thanks
[21:18] <sinzui> thumper: I can do that. 30 minutes? 40?
[21:18] <thumper> 20 should be fine
[21:18] <thumper> the default is 20
[21:18] <thumper> sorry, 10
[21:20] <sinzui> thumper: 20 right. I chage the safe and robust options to use a 20 minute timeout
[21:22] <perrito666> back, sorry
[21:23] <perrito666> k Ill revert the update status patch, the issue will not be solved (as it is there) but it wont be visible (as it was before)
[21:53] <sinzui> katco: Your observation about feature branches verses blocked master is relevent to my expereince when Lp development did the same. The maintenance teams becase a source of blockers, and since they rotates off maintenance quickly, others had to undo the fixes
[21:54] <sinzui> s/because/became/
[21:56] <katco> sinzui: i suppose we're just getting started with this. we'll see how it plays out. i just wanted to make sure to raise the point that i think regardless of whether jes is landed now or after master is unblocked, the end result will be the same both in terms of time to unblock master, and quality of master.
[21:56] <katco> sinzui: but that if we landed jes now, that could be a large positive. so no negatives, one positive
[21:56] <perrito666> http://reviews.vapour.ws/r/2220/
[21:57] <sinzui> katco: Indeed. I had gave hes a higer rank in CI testing because that team had more incenitive fix master. :(
[22:02] <thumper> perrito666: shipit
[22:02] <sinzui> thumper: the 1200s change is in place
[22:02] <thumper> sinzui: cheers
[22:03] <thumper> sinzui: fyi, I'm never going to fix master issues on the jes branch
[22:03] <thumper> sinzui: will always fix in master, then merge master into jes
[22:03] <thumper> sinzui: doesn't make sense to fix in the jes-cli branch
[22:03] <sinzui> fair enough
[22:03] <thumper> so once perrito666's branch lands in master, I'll merge master in jes
[22:03] <thumper> that and the timing fix *should* give us a good shot
[22:04] <thumper> however there are still racy tests in the uniter code, particularly around metrics
[22:04] <thumper> so we may need to hammer it a few times
[22:04] <thumper> fixing the uniter issues is not going to be a quick fix
[22:06] <perrito666> thumper: so, I $$ed the branch, now we wait
[22:06] <perrito666> about racyness
[22:07] <perrito666> the metrics races are better covered since I merged update-status extra hooks since it made clear what was failing (fake timers)
[22:07] <perrito666> s/better covered/a bit les racy
[22:07] <perrito666> and regarding uniter, the race is still there it just lacks coverage
[22:08] <perrito666> idle is still happening at different times in every run we are just not looking at it
[22:36] <perrito666> thumper: merged
[23:05] <axw> wwitzel3: thanks for forward porting my rsyslog fix, forgot about it last week
[23:27] <wwitzel3> axw: thanks for fixing it :)