User1: User2 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
User2: User1 or even break it up
User2: a separate card for ListX
User1: User2 well I'm not sure if that's how it'll work yet. I'll break it up when I have a better idea
User2: ok
User1: User2 will set 8 for now and then break up later, ok?
User2: sure
User2: we'll do more tonight
 * thumper is running tests in windows and locally
User3: god I hate the uniter tests
 * thumper cries quietly as a different test fails intermittently on windows
User4: Bug #1476060 opened: uniter_test.go, startUpgradeError{} fails for windows <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1476060>
User3: User2 do you know much about the unit tests around "update-status"
User3: User2 I have an intermittent failure here
User2: test name?
User2: User3 ?
User3: uniter_test.go: 1351
User3: nope
User3: not that line
User3: line 1310
User2: looking
User3: test desc: 			"all relations are available to config-changed on bounce, even if state dir is missing",
User3: it blocks waiting for hooks
User2: for idle?
User3: start_hooks(false) expects an "update-status" hook call
User3: then on line 1340, it waits for: 			waitHooks{"update-status", "config-changed"},
User3: in the logs, there is only one "update-status" hook call, not two
User2: my line numbers are different
User3: ah... yeah
User3: I'm looking in a branch where I added a few lines further up
User3: due to fixing another bug
User3: sorry
User2: if the next comment after the waitHooks //// Check the state dir was recreated.
User2: is
User2: i can't see anything immediately obvious but horatio has done all that code, reviewed by william. i'll as him to look
User2: how often does it fail?
User3: regularly now on ppc64el and windows
User3: enough to be a critical blocker
User2: but on ubuntu is ok?
User3: yep
User3: wonderful eh?
User2: sigh
User3: and I just fixed a different bug
User2: in uniter?
User3: well, fix is an extreme word
User3: skip a test
 * thumper is submitting now
User2: ah :-)
User3: the bug mentions a failing test
User3: there were two
User3: and I fixed the one this bug didn't mention
 * thumper sighs
User2: ok, we'll take care of this other one
User2: maybe we need to finally gate landings on windows and ppc tests
 * thumper nods
User2: like we've been talking about forever
User3: I have a windows vm running
User2: ooh yuck
User3: there is one thing that looked strange to me
User3: replacing a real timeout value with zero
User3: I'm not convinced that that time.After always works properly with that
User3: seen evidence in other places
User3: perhaps replace with 1 millisecond
User3: rather than zero
User3: User2 http://reviews.vapour.ws/r/2206/diff/#
User2: looking
 * wallyworld forgot he was ocr
User2: sigh
User3: oh...
User3: it is 1 millisecond now
User2: User3 i think also a mock timer was introduced
User3: why do we have both?
User2: to control the triggering of the idle event
User3: s.PatchValue(uniter.LoopIsIdleCheckTime, 1*time.Millisecond)
User3: s.PatchValue(uniter.EnterLoopIsIdleTime, 1*time.Millisecond)
User3: the timing is different on ppc and windows
User2: in what way?
User3: hence, I'm betting this is why we are getting different numbers of calls
User3: scheduler works differently on different architectures / platforms
User2: 1 milli second is too small anyway
User3: these tests aren't checking for idle
User2: no, but update status hook depends on idle
User3: just the update status
User3: ah
User3: poo
User2: update status only fired when idle
 * thumper goes to make a coffee
 * wallyworld is jealous - coffee machine here is broken :-(
User5: thumper or User2 http://reviews.vapour.ws/r/2207/diff/#
User2: User5 +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
User2: that would be ore robust than naming the fields
User5: User2 that's the plan. I'm going to undo the fixes he made.
User2: ok, ty
User5: User2 there's also going to be a PR with DB migrations which fix the currently incorrect records
User2: yay
User5: thumper or User2 http://reviews.vapour.ws/r/2208/
User2: looking
User2: yay
User3: poke me with a fork
User3: I'm done
User3: laters
User6: User7 hangout?
User7: User6 omw, had phone
User6: User15 are you hangoutable?
User4: Bug #1476214 opened: --repository option for 'juju deploy' sometimes has issues with symlinked directories <juju-core:New> <https://launchpad.net/bugs/1476214>
User8: hi
User8: has anyone seen test failures for github.com/juju/juju/service ?
User8: http://paste.ubuntu.com/11909054/
User9: User8 yes I attributed them to my system being dirty
User8: perrito666, ;-]
User9: User8 seems that it is something else
User9: series "\" is certainly wrong
User8: perrito666, yeah - that was my thinking too
User6: User7 could you take a look at http://reviews.vapour.ws/r/2197/ when you have the time?
User7: User6 will take it for you *rofl*
User10: User13 User17 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?
User11: User10 it's not clearl which part of the fix for the bug that is...
User10: User11 The bug lists 3 branches, that is the only one not merged.
User11: okAY, MEENO ADDED TH INFO IN THE BUG
User11: caaaaps
User11: User10 landing it seems good to me, I'll queue
User10: User11 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
User4: 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>
User11: User10 see uniter tests thread on juju-dev list for more fun
User10: mgz :/ I am reading the argument to merge jes-cli snd make it master
User12: 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.
User12: lukasa in #juju would appreciate it i'm sure.
User13: User18 standup
User13: User16 User14 User18 doh just remembered. i will be out over lunch. doc. appt.
User14: User15 thanks for those reviews!
User15: ericsnow, yw, hope they helped
User14: User15 definitely
User15: ericsnow, do you see what I mean about having details nested inside what one whight thing were model packages?
User15: s/thinng/think/
User14: User15 haven't read through the reviews in detail yet :)
User15: ah god I just can't type
User15: ericsnow, let me know if anything bears further discussion :)
User14: User15 will do
User4: Bug #1476214 changed: --repository option for 'juju deploy' sometimes has issues with symlinked directories <juju-core:New> <https://launchpad.net/bugs/1476214>
User4: Bug #1442149 opened: UniterSuite.TestUniterUpgradeConflicts fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1442149>
User7: User6 have to swap offices in a few moments, so I'm not sure if I'll be at the network hangout
User6: User7 OK, join when you can
User7: User6 will do
User6: User7 you merged didn't you... *slap*
User7: User6 I should, shouldn't I ... ;)
User6: User7 rebase! rebase!
User6: User7 it is easy to fix
User6: User7 just a bit annoying
User7: User6 ah, the newest one, hmm, I thought I rebased
User6: User7 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
User6: User7 we can do a rebase on master as a specific task
User7: User6 I do so
User6: User7 odd. Oh well, merge-commit from master onto net-cli, then rebase net-cli on master works to clean things up.
User7: User6 I currently don't work on net-cli
User13: User14 User16 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
User14: User13 lovely
User13: User14 User16 we could begin a pattern wherein we register accessors that return either a json string or interface{}
User13: User14 User16 returning a structured string (json) doesn't strike me as horrible, but it may be a bit different than we're doing things currently
User13: User14 User16 we'll have to see
User16: User13 hrmm, I think json sounds reasonable
User13: User16 i do too... so we would register functions/types that get status for something and have sig func() (string, error)
User13: User16 and then the common apiserver stuff would iterate through those and bundle it in the result
User13: User16 and then the client would have to understand how to parse that
User13: User16 it's just a bit different than we do it now, b/c we have our RPC functionality do that bit for us
User13: User16 i.e. FacadeCall("FullStatus", &statusType) instead of FacadeCall("FullStatus", &jsonString)
User16: User13 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
User13: User16 i don't think it solves our versioning problem, if that's what you're saying
User13: User16 we still have to account for combinations of client & server version
User16: User13 no, not versioning, it simplifies how things look when we start to add and/or refactor other things to components
User13: User16 ah, yes
User10: User13 Do you have a few minutes to review http://reviews.vapour.ws/r/2216/
User17: sinzui, katco is away atm
User10: thank you alexisb
User17: maybe another moonstone team member can help
User17: wwitzel3, natefinch, ericsnow ^^^
User14: User10 done :)
User10: thank you ericsnow
User18: damn beat me
User17: ericsnow is lightning fast!
User13: User17 ty :)
User17: katco, thank you for keeping the team calendar up-to-date :)
User9: User10 hey, is there a way I can procure a ppc machine for a moment to try out some things for the uniter blocker?
User10: User9 I can put your key on stilson-09. You can hack on the same machine that runs the test
User9: User10 that would work
User13: User14 is your state branch landed yet?
User14: yep
User13: User14 cool... does wwitzel3 and natefinch know so they can rebase?
User14: User13 right now trying to land the branch with the fixes for bugs we found while trying to get the demo working
User13: User14 ah ok. so hold off?
User14: User13 for the moment
User14: User13 actually, that shouldn't be a real blocker
User16: yeah, once those fixes land I'll be able to give another end to end run of the wordpress-wpm charm
User16: I cleaned up the charm and fixes up the errors I hit along the way though, so it is pretty good shape now
User13: User16 cool ty
User13: User14 User16 User18 if anyone is interested in what i'm doing, i can pair. some interesting problems
User16: User13 yeah, that sounds good
User13: User16 cool i'll hop in moonstone
User13: User14 hey which struct stores juju's notion of process state?
User14: User13 in what context?
User18: ericsnow or User16 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 :)
User16: User18 will do that now
User13: User14 so when we run juju status, where do i go to get the new process info out of state?
User14: User13 see State.UnitProcesses() (in state/processes.go)
User13: User14 can you join moonstone rq?
User14: User13 sure
User18: back later
User3: User10 if we want ppc64el tests to pass, we NEED to increase the timeout
User19: katco, User14 wasn't this fix landed in 1.25: https://bugs.launchpad.net/juju-core/+bug/1468815
User4: 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>
User14: User19 wwitzel3 is working on that
User19: User14 okay, thanks
User10: User3 I can do that. 30 minutes? 40?
User3: 20 should be fine
User3: the default is 20
User3: sorry, 10
User10: User3 20 right. I chage the safe and robust options to use a 20 minute timeout
User9: back, sorry
User9: 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)
User10: User13 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
User10: s/because/became/
User13: User10 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.
User13: User10 but that if we landed jes now, that could be a large positive. so no negatives, one positive
User9: http://reviews.vapour.ws/r/2220/
User10: User13 Indeed. I had gave hes a higer rank in CI testing because that team had more incenitive fix master. :(
User3: User9 shipit
User10: User3 the 1200s change is in place
User3: User10 cheers
User3: User10 fyi, I'm never going to fix master issues on the jes branch
User3: User10 will always fix in master, then merge master into jes
User3: User10 doesn't make sense to fix in the jes-cli branch
User10: fair enough
User3: so once perrito666's branch lands in master, I'll merge master in jes
User3: that and the timing fix *should* give us a good shot
User3: however there are still racy tests in the uniter code, particularly around metrics
User3: so we may need to hammer it a few times
User3: fixing the uniter issues is not going to be a quick fix
User9: User3 so, I $$ed the branch, now we wait
User9: about racyness
User9: the metrics races are better covered since I merged update-status extra hooks since it made clear what was failing (fake timers)
User9: s/better covered/a bit les racy
User9: and regarding uniter, the race is still there it just lacks coverage
User9: idle is still happening at different times in every run we are just not looking at it
User9: User3 merged
User1: User16 thanks for forward porting my rsyslog fix, forgot about it last week
User16: User1 thanks for fixing it :)
juju-dev
Ubuntu IRC