[00:14] mwhudson: ok [00:40] thumper: why do we use github.com/juju/schema instead of using struct tags? [00:43] natefinch: jw4 might have an opinion === kadams54-away is now known as kadams54_ === kadams54_ is now known as kadams54-away [01:00] axw: can you recall the change in master that flattened storage.Volume ie got rid of VolumeInfo. i'm getting conflicts merging 1.24 and just need to recall which way around it is supposed to be in master [01:12] wallyworld: it's hte other way around, I extracted VolumeInfo from Volume [01:12] axw: right, ty [01:28] davecheney: note, I'm talking our own yaml schema validation stuff for like metadata.yml, not jsonschema, if that's what you were thinking. Pretty sure the schema stuff predates jw4 :) [01:49] oh [01:49] right [01:49] ignore what i said [01:49] i thought you were watlkig about json schema [02:21] fuck fuck fuckity fuck [02:50] thumper: is jessie in today? [02:51] no, leave [02:53] thumper: ah ok, can you remind him next week then to port bug 1441478 to master, i think he forgot [02:53] Bug #1441478: state: availability zone upgrade fails if containers are present

[02:54] i could include it in my forward port, if i can do so without risk i will === kadams54 is now known as kadams54-away [03:06] wallyworld: an old ticket (bug 1318366) has recently been reopened by aaron regarding mgo/txn panics [03:06] wallyworld: it's attached to me b/c I helped fix last year's issue [03:06] oh? [03:07] wallyworld: I think fwereade is looking at this issue ("panic: rescanned document misses transaction in queue") [03:07] wallyworld: do you know? [03:07] yes he's looking [03:07] stuck though [03:08] wallyworld: found the newer ticket: https://bugs.launchpad.net/juju-core/+bug/1449054 [03:08] Bug #1449054: Intermittent panic: rescanned document

[03:08] wallyworld: looks like the fix wasn't merged into trunk though [03:09] wallyworld: I might deal with this now b/c I want to bump the mgo dependency anyway [03:10] menn0: i'm forward porting a bunch of 1.24 vhanges now, which includes the latest mgo from 1.24. trunk has an old copy of mgo from a year ago [03:10] menn0: trunk will soon have the sme dep rev as 1.24 [03:11] or did you want a later one as a new mgo has been released since then [03:11] wallyworld: I want something from the release from a few days ago [03:11] wallyworld: it's not urgent though [03:12] wallyworld: so do your forward port first and i'll handle bumping the dep again afterwards [03:12] ok, i'll hopefully have master up to date (mostly) with 1.24 soon [03:25] wallyworld: are we likely to ever do another 1.22 release? CI opened up a ticket for a test fix for 1.22 recently that we have fixed in later releases but it was never backported that far back. i'm think I can close it unless we might do another 1.22 release. [03:25] wallyworld: got time to hangout? [03:26] thumper: sure [03:26] back in our chat [03:26] kk [03:26] menn0: we might do a 1.22.6 [03:26] menn0: but no decision yet - depends if william finds and fixes the mgo bug [03:26] menn0: so may keep open until decided [03:27] wallyworld: ok. i'll backport this fix. it's a fairly easy one. [03:27] ok [04:14] trivial review for someone: http://reviews.vapour.ws/r/1866/ [04:16] thumper: i shall put a trivial effort into reviewing said [04:16] davecheney: WFM [04:19] i also added a trivial review comment [04:19] it should be trivial for you to address same [04:32] wallyworld: you around? [04:32] yeah [04:33] wallyworld: see PM [04:54] axw: we you have a moment, could you eyeball this for me? it picks up our various 1.24 fixes for storage, leadership, etc, plus the tags stuff. diff is big, but if you know the work, you should be able to peruse through pretty quickly http://reviews.vapour.ws/r/1868/diff/# [04:55] wallyworld: ok [04:55] no rush [04:56] wallyworld: I found why the blockdevices txns are aborting: structs are in a different order in mongo to in the assertion. I have nfi how they got in that order though. current hypothesis is that mgo/txn is deserialising a queued transaction's ops into a bson.M, and so not preserving the order [04:57] oh wonderful [04:57] that could explain it yeah [04:57] axw: doesn't mongo order the struct fields alphabetically? [04:58] wallyworld: no, it stores them in the order you present them. mgo preserves struct field order when encoding to BSON [04:59] ok, i recall something about alphabetically order, but can't remember now [05:10] wallyworld: merge looks fine [05:10] axw: ty, will land and mark a lot ofbugs as fix committed [05:29] axw: reviewed, off for school pickup, bbiab [05:29] wallyworld: thanks. heh, oops, left that && false for debugging [05:29] thought so :-) [06:14] * thumper is done [06:51] Bug #1462213 opened: [Ubuntu Vivid] Cannot bootstrap on local provider [06:59] wallyworld: bleh, I broke managedfs [06:59] wallyworld: haven't merged, will fix that first [06:59] ok [06:59] phew [08:35] wallyworld: FYI I've pushed my fix to the PR. tested manually, going to rebase and merge now === urulama_ is now known as urulama [08:43] axw: great, ty [11:41] voidspace, ping [11:42] voidspace, because I keep forgetting, let me ask you now - please send me the ep2015 talk by mail so I can go over it :) [11:48] * dimitern steps out for a while === liam_ is now known as Guest74348 [11:56] dimitern: I have to find it [11:56] dimitern: but yes - it's not on this computer [11:57] dimitern: it's probably on my laptop - and I'm going downstairs to work as the handyman needs my office === benonsoftware is now known as MerryChristmas === MerryChristmas is now known as benonsoftware [12:30] good morning all [13:32] can someone else try logging on to canonicaladmin? it keeps telling me the username and password is wrong, but they're saved in my password manager, so I'm sure they're not wrong [13:33] wfm natefinch [13:33] hmm... possibly related: https://www.youtube.com/watch?v=Lz9810Y7ZRw [13:34] natefinch: In a company I once worked that meant talk to rrhh :p [13:34] yeah, exactly that video [13:34] natefinch: works for me, still ugly as hell [13:36] weird [13:57] ericsnow: do we support vivid on 1.22? re: https://bugs.launchpad.net/bugs/1462213 [13:57] Bug #1462213: [Ubuntu Vivid] Cannot bootstrap on local provider [14:02] natefinch: no [14:02] natefinch: not for the local provider specifically [14:07] Bug #1462213 changed: [Ubuntu Vivid] Cannot bootstrap on local provider === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === katco` is now known as katco [15:16] Bug #1462409 opened: FilesystemStateSuite setup failed

[15:25] Bug #1462409 changed: FilesystemStateSuite setup failed

[15:34] Bug # opened: 1462409, 1462412, 1462415, 1462417, 1462418 [15:37] Bug # changed: 1462412, 1462415, 1462417, 1462418 [15:42] katco: which hangout are we supposed to be in now? I'm in retrospective, but no one else is [15:42] natefinch: we all went back to moonstone [15:46] Bug # opened: 1462412, 1462415, 1462417, 1462418, 1462423 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [16:32] Bug #1457645 changed: warning: log line attempted over max size - leadership related

[16:53] Bug # changed: 1376246, 1431372, 1454678, 1454891, 1457728, 1459057, 1459060, 1459250, 1459611, 1459616, 1459885, 1459912, 1461111, 1461342 [17:35] ericsnow: wwitzel3: you 2 back yet? === kadams54 is now known as kadams54-away === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [19:58] why doesn't this command work in 1.24-beta5? juju get-env admin-secret [20:00] let me rephrase, how can I programatically get the password/admin-secret for an environment from the command line without doing `grep "admin-secret" ~/.juju/environments/gce.jenv | awk '{ print $2 }'` [20:02] marcoceppi: should you use the admin secret any more vs the password? can you programatically get the password? [20:02] ericsnow, wwitzel3 ^^ any idea? [20:02] rick_h_: I tried password [20:02] it said that key does not exist [20:02] marcoceppi: oh hmm, might mention that one to thumper [20:02] marco@galago:~$ juju environment get password [20:02] ERROR key "password" not found in "gce" environment. [20:03] marcoceppi: is this a GCE-specific issue? [20:03] this is every environment [20:04] k [20:04] yea, would guess no, more a general thing [20:04] marco@galago:~$ juju environment get password [20:04] ERROR key "password" not found in "aws-west-2" environment. [20:04] also, environment doesn't accept an -e flag :( [20:04] oh, but get does [20:04] oops [20:04] hahaha [20:04] ah, I don't know a ton about the new environment management stuff [20:05] well, get-env has been around for a while [20:05] probably the 1.18 days [20:05] we were just talking about the -e stuff in a bug report [20:05] which is an alias to environment get [20:05] marcoceppi: https://bugs.launchpad.net/juju-core/+bug/1461605 [20:05] Bug #1461605: juju action commands require -e in the "wrong" place

[20:06] marcoceppi: the comments on the bug go beyond just actions thought [20:06] s/thought/though [20:06] basically all the new "double command" commands "action do" "environment get" require the -e after the second command [20:07] natefinch: cool, but I really just need to get the password programmatically now ;) [20:07] heh [20:07] * marcoceppi goes back to just grep and awk though he's aware of some shake up around .jenvs [20:12] behold. grep "admin-secret" ~/.juju/environments/$(juju switch).jenv | awk '{ print $2 }' === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [21:19] my vim is all confused of having python in it again [22:46] getting this error when trying to build in golang [22:46] ../../../gopkg.in/juju/charm.v5/meta.go:19: import /home/marco/.go/pkg/linux_amd64/gopkg.in/juju/charm.v5/hooks.a: object is [linux amd64 go1.2.1 X:none] expected [linux amd64 go1.3.3 X:precisestack] [22:46] I have go 1.3.3 installed [22:47] not sure what I did or how to fix this [22:48] marcoceppi: rm -rf $GOPATH/pkg [22:48] and try again [22:48] gsamfira: I ended up blowing away charm.v5 and re-getting it [22:49] seemed to sort it, thanks [22:49] I'm trying to print a reference [22:49] because I want to know what it's about and I can't figure it out normally, "cannot use ref (type *charm.Reference) as type string in argument to fmt.Printf" so obviously Printf isn't my friend === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54 is now known as kadams54-away