[01:14] how are we doing on those blockers ? [01:15] mwhudson: did you fix http://pad.lv/1494441 [01:15] > [01:15] thumper: re #1495320, why should we have any of those things? IMO we should have per-facade mock states, which is what some of the newer facades have been doing already [01:15] Bug #1495320: New base test suite for apiserver

[01:17] axw: fair point... [01:35] wallyworld: FYI, https://bugs.launchpad.net/juju-core/+bug/1495338 [01:35] Bug #1495338: cmd/juju/storage: "volume list" YAML/JSON format is non-obvious [01:35] np, ty [01:37] axw: this is a nice bug :D i wish they were all like that! [01:59] Bug #1495338 opened: cmd/juju/storage: "volume list" YAML/JSON format is non-obvious

[02:10] thumper: waigani: please don't use JujuConnSuite for testing new apiserver facades [02:11] there's plenty of existing apiserver facades that have been written with better tests you can copy fro [02:11] wallyworld: okay, sorry [02:12] waigani: best not to perpetuate our misery :-) [02:12] especially for new work [02:12] adding a new test i could live with [02:12] but a whole new facade package, not really [02:13] wallyworld: yep, understood - fixing it now [02:14] waigani: there should be a happy path feature test though that (for now) does use jujuconnsuite to ensure it is glued together end-end [02:15] in the featuretests package [02:17] wallyworld: I was going to add a feature test once the api and worker have landed, to make sure they all work as intended. [02:27] wallyworld anastasiamac: how's this look as an alternative "volume list" YAML format? http://paste.ubuntu.com/12405626/ [02:28] axw: "machines" as a collection? :D [02:28] looks nice :)) [02:28] wallyworld anastasiamac: there will be a "units" field below "machines" when the data is available in the API [02:28] \o/ [02:28] personally, i like :) [02:28] axw: "provider-id" - could that be just "id", or "volume-id" [02:29] wallyworld: hum, I'm trying to distinguish between the internal and provider-supplied one. it's kinda ambiguous [02:29] yeah [02:29] axw: is status per volume or machine/unit? coz what does "attached" mean when there r 1+ machines/units? [02:30] anastasiamac: currently only per volume, but later we'd have per-machine and per-unit also (and they'll go in the "machines" struct, along with "device" and "read-only" [02:30] anastasiamac: atm, "attached" means all attachments are created [02:31] otherwise it's "attaching" [02:32] axw: sounds great! let's remember to deal with/display multiple status when we have per-machine and per-unit specific ones :D [02:32] anastasiamac: I'll adda TODO in the relevant structs [02:32] axw: tyvm for making output user-helpful \o/ [02:33] anastasiamac: np [02:33] axw: the id i think should be whatever we expect the user to use when we add CLI that requires it to identify a volume [02:33] wallyworld: yeah, that's the top-level string "1/0" [02:33] wallyworld: same sort of format for machine IDs as in "juju status" [02:34] ok, yeah, that makes sense [02:38] wallyworld: so, yea or nay? [02:38] axw: oh sorry, +1 i think [02:39] is the user generally inetrested in provider id? [02:39] could it be left off? [02:39] wallyworld: same level of interest as people have in instance IDs [02:39] wallyworld: useful for matching up juju resources with things in your cloud provider [02:40] so it adds value in showing it [02:40] wallyworld: I think so [02:40] sgtm [02:47] wallyworld: got 10 minutes for a quick chat about a critical bug? [02:47] wallyworld: it has to do with the new uniter code [02:47] sure [02:47] https://bugs.launchpad.net/juju-core/+bug/1494356 [02:47] Bug #1494356: OS-deployer job fails to complete

[02:47] 1:1 hangout [03:14] Bug #1495320 changed: New base test suite for apiserver

[03:17] Bug #1495320 opened: New base test suite for apiserver

[03:23] Bug #1495320 changed: New base test suite for apiserver

[03:29] Bug #1495320 opened: New base test suite for apiserver

[03:32] Bug #1495320 changed: New base test suite for apiserver

[03:40] ah fuck [03:40] my passport hits the <6 months until expiry mid-sprint [03:41] you shall receive an imigration fail [03:42] 3 weeks, you should be able to get an expidited one by then [03:44] 10 working days for NZ is normal [03:44] File type: Jpg or Jpeg [03:44] heh [03:44] for photo [03:47] will they accept JPEG ? [03:47] hmm... deems dubious [03:48] seems [03:50] thumper: i got my passport in 2 days after paying an exhorbitant fee after i put it through the wash 10 days before the malta sprint [03:51] heh [03:51] I don't want to pay the 2x amount for 3 day shipping [03:51] 10 should be fine [04:03] davecheney: yes, but the fix will take a loong time to get anywhere i suspect [04:11] mwhudson: that's what I figured [04:11] it looks like the commit that used the encoding package got rolled back for unrelated reasons [04:11] can we mark that issue as not a blocker for now ? [04:12] i don't actually understand all steps of the process by which the fix will get into trusty-updates, i guess it would be good to learn that [04:12] but oops, i'm supposed to be on leave today :-) [04:18] wallyworld: http://reviews.vapour.ws/r/2650/ [04:18] looking [04:19] thumper: +1 [04:19] wallyworld: pretty dull fix I admit [04:21] ship it [04:29] oh fuck [04:29] * thumper found a bad bug [04:29] testing bug only [04:29] windows only [04:29] but bad none the less [04:30] * thumper things [04:30] and thnks [04:30] * thumper gives up [04:33] * thumper head-desks [04:37] MEH [04:38] anyone got a windows 2012 image running? [04:38] wallyworld: another quick sanity check chat? [04:38] sure [05:02] wallyworld: http://reviews.vapour.ws/r/2651/diff/# [05:02] looking [05:04] thumper: thanks for fixing that [05:04] wallyworld: np [05:16] davecheney: that last one was just a windows time bomb [05:16] davecheney: it was bound to fail eventually [05:16] :) [05:31] thumper: http://pastebin.ubuntu.com/12406461/ [05:32] thumper: first three is using jujuconnsuite [05:32] thumper: second three, after pop, are using a mock state [05:39] wallyworld, thumper: updated PR: http://reviews.vapour.ws/r/2649/ [05:39] looking [05:51] waigani: i don't like how getEnvironment is patched. hopefully my comments make sense [05:51] it's unnecessary [05:51] wallyworld: okay, thanks for the review [05:54] wallyworld: btw rewriting from jujuconnsuite to mock state afforded me the opportunity to benchmark the two: http://pastebin.ubuntu.com/12406461/ [05:54] wallyworld: after the pop is with the mock [05:55] waigani: yeah. although even with the mock the numbers look too high [05:55] i would expect say 5 or 10ms [05:55] but still a good reduction [05:55] hmm, that could be my laptop.. [05:55] maybe there's something else there that needs fixing also [05:56] waigani: did you remember to remove the ngotestsuite [05:56] wallyworld: I think so... I'll check [05:57] wallyworld: good catch, that was it. [05:58] thought so :-) [05:58] i didn't believe you when you said you'd removed it :-) [05:59] axw: this fixes a ci blocker, removes a crappy initial port of the update status stuff that i did http://reviews.vapour.ws/r/2652/ [05:59] wallyworld: okey dokey, looking [06:03] wallyworld: is operation.State.UpdateStatusTime used at all after these changes? [06:04] axw: no, not supposed to be, did i forget to remove it [06:04] wallyworld: I think so [06:04] ffs, so i did [06:05] wallyworld: can you please explain how it was spinning before? [06:06] tl;dr; the decoupling of remote state from the update status hook action meant that the previous helper to find the duration to wait based on now and last fire time would always trigger a very short wait [06:06] and that would caue the timer to fire again [06:06] and again [06:06] and again [06:06] wallyworld: ah, I see [06:07] the old world and new didn't match [06:07] wallyworld: so now we always just wait for the full period, right? [06:07] wallyworld: and if somethign else happens within that period, we'll wait again for another full period [06:07] yeah, but all we do is update the counter [06:07] yep [06:08] each time the update status hook runs, it sets current value to current counter [06:08] counter could be +10 or +20 over last local recorded value, we dont care [06:08] we just wait till idle and see if counters are different [06:09] wallyworld: yeah I was just thinking about the difference in when the remote state watcher is triggered. I think with this change we'll never set status until the unit has quiesced, and *then* the update-status idle period has elapsed [06:09] as opposed to period since the last update [06:09] wallyworld: (which seems fine to me) [06:09] me too [06:09] because when hooks are run, unit can set status [06:10] so it could have done it during config changed or something [06:11] wallyworld: thanks. reviewed [06:11] tyvm [06:11] axw: i had a small unit test that showed the spinning, but it used wall clock so i removed it [06:12] i'll test live also after school pickup [08:10] wallyworld: don't suppose you're still working are you? [08:13] axw: hey [09:58] frobware: dimitern: TheMue: dooferlad: morning, I'm back in the UK [09:58] voidspace, morning :) [09:59] voidspace, hiya [09:59] voidspace: welcome back. Enjoy the rain! [10:00] o/ [10:01] dooferlad: hehe, we had quite a lot of rain (warm rain though) in North Carolina. A couple of impressive thunderstorms. [10:01] dooferlad: a few days of good sun too though. [10:02] dimitern: frobware: so fwreade gave me a comprehensive review on my "unit public address branch" [10:02] dimitern: frobware: I've already started work on it - the biggest change is to set the "preferred addresses" (he doesn't like the Default name) when the addresses are set rather than when they're fetched [10:03] dimitern: frobware: plus a bunch of issues he identified in existing code that the PR touches [10:03] dimitern: frobware: so that's what I'm up to... [10:03] frobware: when is good for you to chat? [10:03] voidspace, now is good. [10:03] frobware: cool [10:04] frobware: hmm.... the one-to-one isn't on my calendar for some reason [10:04] frobware: what hangout should we use? [10:05] voidspace, I just sent you an invite (https://plus.google.com/hangouts/_/ejtwk7d5mqnwljcwmbxkvzi2uaa?hl=en-GB&authuser=0) [10:06] frobware: gah, I have to do the authentication dance - there in a minute [10:18] frobware: https://bugs.launchpad.net/juju-core/+bug/1435283 [10:18] Bug #1435283: juju occasionally switches a units public-address if an additional interface is added post-deployment

[10:20] frobware: http://reviews.vapour.ws/r/2593/ [10:23] voidspace, I'm fine with calling it preferred instead of default [10:30] dimitern: yeah, me too [12:12] mwhudson, anyone else: do you know the status of this bug? https://bugs.launchpad.net/juju-core/+bug/1494441 [12:12] Bug #1494441: ppc64el: cannot find package "encoding"

[12:19] hey, if I wanted to stop/start juju mongo on local provider, where would I find the start/stop script? [12:26] meh systemv [12:42] jam1: any idea if this bug is likely to be fixed, by any chance? https://bugs.launchpad.net/juju-core/+bug/1494441 [12:42] Bug #1494441: ppc64el: cannot find package "encoding"

[12:42] jam1: it's blocking us currently === akhavr1 is now known as akhavr === jam1 is now known as jam [12:45] rogpeppe: this is the first that I've heard of the problem. It is marked as In Progress my mwhudson [12:46] jam: ok, thanks. i'll wait for him to come online [12:46] which might be the patch he proposed, I'm not sure the timeline for getting that actually into the trusty gcc-go build [12:46] alexisb would be another person to raise awareness of the bug to [12:52] wallyworld, just saw the news, congratulations [12:53] mattyw: 4th one in 5 years :-( [12:53] as bad as italy [12:53] wallyworld, you going to put your name forward? [12:53] thinking about it [12:54] can't do any worse === akhavr1 is now known as akhavr [13:03] ok, I have been pushing through a filthy headache for a while, and I'm not actually getting anything done [13:03] * fwereade goes to lie down === natefinch-afk is now known as natefinch [14:22] Bug #1495542 opened: 1.20.x cannot upgrade to 1.26-alpha1

[14:27] ericsnow: natefinch: looks like there is a new blocker: 1495542 [14:27] bug 1495542 [14:27] Bug #1495542: 1.20.x cannot upgrade to 1.26-alpha1

[14:28] katco: related to #1494070, perhaps? [14:28] Bug #1494070: unit agent upgrade steps not run

[14:28] ericsnow: sounds plausibly correct. sinzui is that a dupe? [14:30] ericsnow: at any rate, pick that one up and maybe you'll find they're the same thing [14:30] ericsnow: pick the blocker up that is [14:30] katco: k [14:30] godspeed, ericsnow [14:30] katco: my guess is it's not related [14:31] I've always wanted to say that [14:31] katco: as we have to un-run upgrade steps, one long standing, and casey hacked around the other one [14:32] katco, natefinch: FYI, looks like the 1.25-beta1 list has several open that have been resolved [14:33] ericsnow: example? [14:34] katco: #1465317 [14:34] Bug #1465317: Wily osx win: panic: osVersion reported an error: Could not determine series

[14:34] katco: ericsnow Well, if that bug is a dupe then it isn't 100% correct. http://reports.vapour.ws/releases/3049/job/aws-upgrade-20-trusty-amd64/attempt/8 shows 1.20 can upgrade to 1.25 [14:34] may or may not be forward-ported [14:35] ericsnow: what makes you say this is resolved? [14:36] katco: fixed in an earlier version [14:36] ericsnow: how do you know that? and why isn't this bug targeted to that version? [14:36] * ericsnow only skimmed through, so only a quick estimation [14:37] katco: sorry, bad example [14:37] ericsnow: no worries, just trying to get up to speed [14:37] katco: #1468815 is better [14:37] Bug #1468815: Upgrade fails moving syslog config files "invalid argument"

[14:38] ericsnow: k, same question... what makes you think it's resolved in 1.25-beta? [14:38] katco: it *might* be resolved already [14:38] ericsnow: based on what? [14:39] katco: fix-released on 1.24 [14:39] ericsnow: so you're thinking 1.25-beta1 was cut after this fix was released? [14:40] katco: rather that someone may have forward-ported and not updated the ticket [14:40] katco: or that it just needs a forward-port [14:41] ericsnow: couldn't we say that about any bug? [14:41] katco: sure, as long as it's been fixed in an earlier release [14:42] katco: another example: #1449054 [14:42] Bug #1449054: Intermittent panic: rescanned document

[14:42] ericsnow: hm. just unsure why someone would go through the trouble of forward-porting without updating the bug. [14:43] katco: sometimes folks simply merge an earlier branch forward, picking up multiple fixes [14:43] ericsnow: ah, this is the whole merge vs. cherrypick issue? [14:43] katco: sometimes === natefinch is now known as natefinch-afk [14:44] katco: anyway, at the least there are some bugs on that list that may just need forward-porting [14:44] ericsnow: yep [14:44] katco: I guess that was my original point lol [14:44] ericsnow: thanks for walking me through your thought process [14:44] katco: haha [14:45] ericsnow: no seriously :) just wasn't understanding how you arrived at that conclusion [14:45] katco: mostly I skimmed through the list and several looked like ones we'd already fixed :) [15:50] hi peeps, this PR was backed out earlier because of issues not directly related to the PR itself. This is a re-proposal: https://github.com/juju/juju/pull/3275 [15:50] could someone please rubberstamp it please? [16:03] dimitern: ping! [16:04] dimitern, voidspace: https://plus.google.com/hangouts/_/canonical.com/networking?authuser=0 [16:04] dooferlad, omw [16:07] rogpeppe, looking [16:07] cmars: thanks [16:08] cmars: though i already have two reviews, just waiting for the juju blockage clouds to lift momentarily so i can land it [16:16] Bug #1495591 opened: TestRunCommand fails on windows

[16:18] dooferlad: omw [16:19] dooferlad: thanks [16:19] dooferlad: ah, I'm late [16:19] Bug #1495591 changed: TestRunCommand fails on windows

[16:25] Bug #1463408 changed: TestRunCommand fails

[16:25] Bug #1495591 opened: TestRunCommand fails on windows

[16:28] Bug #1463408 opened: TestRunCommand fails

[16:40] Bug #1463408 changed: TestRunCommand fails

[16:54] here's a mostly-cosmetic change to the apiserver internals. review appreciated: http://reviews.vapour.ws/r/2656/ === natefinch-afk is now known as natefinch [18:07] katco: ping [18:07] jam: pong [18:08] katco: hi. are you able to meet tomorrow sometime early-ish in your morning? [18:09] jam: sure [18:09] jam: calendar is up to date [18:09] 11 or 12 utc ? [18:10] jam: 12 would work better, but can make either time [18:15] jam: thx for taking the time to meet [18:16] katco: happy to [18:26] that feeling when you've changed a whole bunch of code and finally get it all compiling... and the tests all pass on the first try. [18:26] <_< [18:26]