[00:01] <wallyworld> menn0: if i have a txn-queue uuid from a db.lease.find(), what's the cmd to show the queue size?
[00:02] <menn0> wallyworld: the queue size is literally the length of the txn-queue field on the document (it's an array)
[00:02] <wallyworld> ah right, the array is length 1 with a uuid
[00:02] <wallyworld> on  a system with 5 units
[00:02] <menn0> wallyworld: a single item in the array is totally normal
[00:03] <wallyworld> yep
[00:03] <menn0> mgo/txn leaves the last txn that touched a document in the field
[00:04] <wallyworld> i guess i've leave it run for a bit nd see if the queue size explodes
[00:04] <menn0> wallyworld: the system that experience that bug had a number of services deploy
[00:04] <menn0> deployed
[00:04] <wallyworld> i have 2
[00:04] <wallyworld> with 5 units each
[00:04] <wallyworld> i can add more
[00:04] <menn0> wallyworld: this one had 8 or something, not sure if that makes a difference
[00:04] <menn0> wallyworld: are you try to repro with master or checking your fix?
[00:05] <wallyworld> my fix
[00:05] <wallyworld> maybe a should have repoed first
[00:05] <wallyworld> i might try a bundle
[00:05] <menn0> wallyworld: it would be good to know if you can see the problem with master first, otherwise you don't know whether you've actually helped
[00:05] <wallyworld> true, i just assumed it would show up with enough load
[00:07] <wallyworld> deploying landscape bundle anyhow, we'll see what happens
[00:23] <wallyworld> axw: anastasiamac: i have to head out for a blood test, been fasting for 12 hours. bbiab with food :-)
[00:23] <anastasiamac> wallyworld: good luck :D
[00:24] <wallyworld> i studied all night
[00:24] <wallyworld> hope i pass
[00:28] <menn0> waigani: is there any reason why this PR hasn't been reviewed yet? http://reviews.vapour.ws/r/1748/
[00:28] <menn0> waigani: never mind
[00:28] <menn0> waigani: I just saw that it's a forward port
[00:29] <menn0> waigani: to avoid having these clutter up RB i've been manually marking them as submitted in RB even before they get merged
[00:29] <menn0> waigani: it avoids some confusion
[00:54] <waigani> menn0: okay, I'll do that in the future.
[01:10] <mup> Bug #1459057 was opened: multiple storage-add constraints for the same storage unsupported <juju-core:New> <https://launchpad.net/bugs/1459057>
[01:13] <mup> Bug #1459060 was opened: add support for "storage-add <name>" <juju-core:New> <https://launchpad.net/bugs/1459060>
[01:19] <axw> menn0: would you kindly take another look at http://reviews.vapour.ws/r/1781/
[01:25] <mup> Bug #1459060 changed: add support for "storage-add <name>" <juju-core:New> <https://launchpad.net/bugs/1459060>
[01:31] <davecheney> % tree | grep logger
[01:31] <davecheney> │   ├── logger
[01:31] <davecheney> │   │   ├── logger.go
[01:31] <davecheney> │   │   ├── logger_test.go
[01:31] <davecheney> │   ├── logger
[01:31] <davecheney> │   │   ├── logger.go
[01:31] <davecheney> │   │   ├── logger_test.go
[01:31] <davecheney> │   ├── logger
[01:32] <davecheney> │   │   ├── logger.go
[01:32] <davecheney> │   │   ├── logger_test.go
[01:32] <davecheney> │   │   │   ├── logger.go
[01:32] <davecheney> juju has at least three packages called logger !>!
[01:32] <davecheney> how does this help anything ?
[01:33] <anastasiamac> davecheney: the more the merrier? :D
[01:40] <mup> Bug #1459060 was opened: add support for "storage-add <name>" <juju-core:New> <https://launchpad.net/bugs/1459060>
[01:40] <davecheney> you get a logger! and you get a logger! and you get a logger! /oprah
[01:48] <thumper> davecheney: pretty sure those are all mine :)
[01:48] <thumper> davecheney: at least I didn't call it "state"
[01:48] <anastasiamac> :D
[01:49] <menn0> axw: ship it! looks great.
[01:49] <axw> menn0: cheers
[01:50] <menn0> axw: sorry it took me a while, had to go to the post office
[01:50] <axw> no worries
[01:53] <davecheney> so, today i'm looking at races in the logger and leadership packages
[01:53] <davecheney> but I can't figure out which one i need to look at
[01:53] <axw> davecheney: leadership and lease are in flux a bit, FYI
[01:53] <axw> there's some critical bugs that need fixing
[01:54] <davecheney> eek
[01:55] <davecheney> http://paste.ubuntu.com/11381996/
[01:57] <davecheney> axw: https://bugs.launchpad.net/juju-core/+bug/1459064
[01:57] <mup> Bug #1459064: worker/leadership: data races in test and code <juju-core:New> <https://launchpad.net/bugs/1459064>
[01:57] <axw> joy
[02:03] <wallyworld> menn0: \o/
[02:04] <menn0> wallyworld: ?
[02:04] <wallyworld> trivially reproducable
[02:04] <wallyworld> "txn-queue" : [        "5565255b0c132d0fb0000150_978b92fe",    "556525790c132d0fb0000198_5c4423d2",    "556525970c132d0fb00001b8_741af2e9",       "556525b50c132d0fb00001cb_36de73a9",    "556525d30c132d0fb00001ef_156997b6" ]
[02:04] <wallyworld> and my fix works
[02:04] <menn0> sweet!
[02:04] <menn0> that's great news
[02:04] <wallyworld> yeah
[02:04]  * wallyworld goes to hit merge
[02:04] <menn0> now i'm curious as to what you changed
[02:04] <menn0> i'll have to check out the diff
[02:05] <wallyworld> it's not a complete fix for all the issues
[02:05] <wallyworld> just this one specific thing
[02:05] <thumper> wallyworld: have you fixed leadership?
[02:05] <thumper> oh...
[02:06] <wallyworld> thumper: one teeny little bit
[02:06] <thumper> are ya gunna fix it all?
[02:06] <wallyworld> axw will :-)
[02:06] <wallyworld> we are both working on it
[02:06] <wallyworld> and illiam
[02:06] <wallyworld> w
[02:07] <mup> Bug #1459064 was opened: worker/leadership: data races in test and code <juju-core:New> <https://launchpad.net/bugs/1459064>
[02:08] <menn0> wallyworld: one thing to check... do the txn-queue entries get automagically fixed when upgrading from a system with the bug to one with your fix?
[02:08] <wallyworld> menn0: that's a good point. i guess i should try that
[02:08] <wallyworld> since this started in 1.23 :-(
[02:09] <wallyworld> if it were 1.24 betas, i wouldn't bother
[02:09] <wallyworld> menn0: if it's not fixed, what would the answer be run the txn purge tool
[02:09] <wallyworld> ?
[02:10] <menn0> wallyworld: I guess the new txnpruner worker should take care of them
[02:10] <menn0> wallyworld: b/c they are completed txns
[02:10] <wallyworld> i'll try it out
[02:11] <menn0> wallyworld: actually, it won't
[02:12] <menn0> wallyworld: b/c the txnpruner doesn't modify the txn-queue field. it only removes docs from the txns collection for completed txns that are no longer referenced
[02:12] <menn0> wallyworld: so it won't help
[02:12] <wallyworld> menn0: i'm worried this is a time bomb which will hit other deployments
[02:12] <menn0> wallyworld: but I have a feeling that mgo/txn may tidy up the txn-queue fields for you
[02:12] <wallyworld> we'll see soon once my deployment bootstraps and i upgrade
[02:13] <menn0> yep. fingers crossed.
[02:39] <wallyworld> menn0: my upgrade hung the state server - i think i may have hit bug 1457728. but in any case, i'm thinking maybe it might be best just to wipe the lease collection on upgrade
[02:39] <mup> Bug #1457728: `juju upgrade-juju --upload-tools` leaves local environment unusable <local-provider> <upgrade-juju> <vagrant> <juju-core:Triaged> <juju-core 1.24:In Progress by axwalk> <https://launchpad.net/bugs/1457728>
[02:40] <menn0> wallyworld: is that safe?
[02:41] <wallyworld> i think so. i'll try upgrading again first
[03:17] <menn0> wallyworld: is one result of your PR that ClaimLeadership doesn't block forever? that's the issue that's causing me hassles at the moment
[03:17] <wallyworld> menn0: that aspect is not deliberately fixed
[03:18] <menn0> wallyworld: ok. i'll have to figure out another way to do this
[03:18] <wallyworld> might be by accident, but there was no intent to change that behaviour
[03:18] <wallyworld> menn0: what s the scenario
[03:18] <menn0> wallyworld: i'm creating feature tests to ensure that logging to mongodb works
[03:19] <menn0> wallyworld: the one that spins up the machine agent works
[03:19] <menn0> wallyworld: the unit agent variant hangs during teardown
[03:19] <wallyworld> ah, deadlocks on test teardown - william has found ways to work around that
[03:19] <menn0> wallyworld: it's because in the unit agent the leadershiptracker hangs making it's initial request for leadership
[03:20] <wallyworld> menn0: i'm am fairly sure william has been through this pain and i though he had a solution
[03:20] <menn0> wallyworld: I suspect it's possibly also b/c i'm using JujuConnSuite so there isn't a full set of workers running on the server side
[03:20] <wallyworld> possibly
[03:20] <menn0> wallyworld: which is possibly why it's getting stuck in the first place
[03:20] <menn0> wallyworld: but i don't know how the lease/leadership stuff works all that well
[03:21] <menn0> wallyworld: i'll bug will if I don't get anywhere by EOD
[03:21] <wallyworld> yeah, i'd ask william, i'll mention it as i'm meant to be talking to him later
[03:21] <wallyworld> menn0: until a proper worker with tombs is used, and the singleton goes away, it will remain broken
[03:22] <menn0> wallyworld: ok
[03:22] <menn0> wallyworld: i'm just wondering if I can get enough infrastructure in place so that leadership does work in the tests
[03:23] <wallyworld> menn0: ack, but sadly i can't give you a good answer
[03:23] <mup> Bug #1459082 was opened: flag for debug-hooks to skip non-existent hooks <debug-hooks> <juju-core:New> <https://launchpad.net/bugs/1459082>
[03:24] <menn0> wallyworld: np, thanks
[03:37] <menn0> wallyworld, thumper: I think I just cracked it. spinning up the lease manager loop allows the leadership functionality in the uniter to work and unblocks the test.
[03:37] <wallyworld> ah, that sounds plausible - i didn't realise the loo[ wasn't running
[03:38] <wallyworld> menn0: when/if you have a moment, i'd like to check something wth you about upgrades, maybe ping me when you've done writing tests
[03:38] <menn0> wallyworld: under JujuConnSuite it's not
[03:38] <wallyworld> :-(
[03:39] <menn0> wallyworld: i wouldn't have expected it to... JujuConnSuite gives you State and an API server but not necessarily all the workers that the state servers run
[03:39] <wallyworld> that's true
[03:39] <wallyworld> but 'tis a trap
[03:47] <menn0> wallyworld: yep and it's a hard to diagnose trap
[03:47] <menn0> wallyworld: i'll be free in a sec to discuss that upgrade issue
[03:47] <wallyworld> ok, ta, see you in onyx
[03:50] <davecheney> thumper: https://bugs.launchpad.net/juju-core/+bug/1459085
[03:50] <mup> Bug #1459085: worker/logger: data race in tests <juju-core:New> <https://launchpad.net/bugs/1459085>
[03:50] <davecheney> this is a bug in loggo
[03:50] <davecheney> i have a fix to propse
[03:50] <davecheney> which branches of juju does this need to land on >
[03:50] <davecheney> which branches of juju does this need to land on ?
[03:51] <thumper> hmm
[03:51] <thumper> davecheney: what is the loggo data race?
[03:52] <thumper> davecheney: go test -race in loggo seems fine... perhaps we need more coverage?
[03:52] <thumper> davecheney: the races probably need to land on master
[03:52] <thumper> unless they are obviously fixing broken behavour in supported jujus
[03:53] <davecheney> i'm on the fence on that one
[03:53] <davecheney> if I can avoid spending a day nursing it back to 1.22
[03:53] <davecheney> i'd prefer to avoid it
[03:54] <davecheney> thumper: btw, you going to land this ?
[03:54] <davecheney> https://github.com/juju/loggo/pull/6
[03:54]  * thumper looks
[03:55] <thumper> no
[03:55] <thumper> decided against it
[03:56] <davecheney> thumper: then close it
[03:56] <davecheney> thumper: https://github.com/juju/loggo/pull/11
[03:56] <davecheney> will try to add a test
[03:57] <davecheney> it is likely that older versions of the race detector cna't spot this bug
[03:57] <thumper> davecheney: just did
[03:57] <thumper> close it that is
[03:57] <thumper> I wonder if the bot is doing this yet
[03:57]  * thumper pokes to see
[03:58] <thumper> davecheney: ah... ok
[03:58] <thumper> davecheney: without this patch, do the current loggo tests exhibit a problem?
[03:58] <thumper> I'm guessing no, because I don't have goroutines doing things in the tests
[03:58] <davecheney> ok, the loggo tests dno't trigger this because they always use ConfigureLogger which uses a mutex which acts as an accidenal memory barrier
[03:59] <davecheney> to trigger it you need to do; logger.SetLevel(x); go logger.LoggerInfo()
[03:59] <davecheney> it has to be in a second goroutine otherwise by definition there is not race
[04:03] <davecheney> lemmie try to add a test as well
[04:03] <davecheney> i'll do that in another PR
[04:06] <thumper> davecheney: looks like there is a bot
[04:11] <mup> Bug #1459085 was opened: worker/logger: data race in tests <juju-core:New> <https://launchpad.net/bugs/1459085>
[04:14] <davecheney> thumper: hmm, this is going to be tricky to write a test for
[04:14] <davecheney> let me try a bit more, then give up if the worker/logger test's race is fixed
[04:16] <natefinch> son of a.... ERROR juju.worker runner.go:219 exited "upgrader": invalid series "wily"
[04:17] <natefinch> haven't we fixed this dumb bug by now?
[04:17] <natefinch> (the "Juju doesn;t know about future series" bug
[04:19] <natefinch> wallyworld, thumper ^  thoughts on how I can get around this?  I just want to test the upgrade step I'm writing
[04:20] <wallyworld> natefinch: install the distro info package
[04:20] <wallyworld> juju can't guess what a new series is
[04:20] <natefinch> wallyworld: but it can install the distro info package itself :/
[04:20] <wallyworld> i guess so, yeah
[04:21] <wallyworld> natefinch: any progress on bug 1370896 as we need to look to get 1.24 wrapped up
[04:21] <mup> Bug #1370896: juju has conf files in /var/log/juju on instances <canonical-bootstack> <logging> <rsyslog> <juju-core:Triaged by natefinch> <juju-core 1.24:In Progress by natefinch> <https://launchpad.net/bugs/1370896>
[04:22] <natefinch> wallyworld: exactly what I'm working on.  We need an upgrade step to move the config files from the old location to the new location.
[04:22] <wallyworld> makes sense
[04:22] <wallyworld> you should be in bed anyway
[04:22] <davecheney> thumper: got a test
[04:22] <davecheney> it's going to come with a LARGE comment
[04:23] <natefinch> wallyworld: well, I work when I get a chance, sometimes having 3 kids under 4 years old means that chance is quite late at night
[04:23] <wallyworld> 3!!
[04:23] <wallyworld> you've been busy
[04:24] <wallyworld> s/quite/very
[04:24] <natefinch> wallyworld: heh, yeah, we had our third, a boy, on Christmas eve.   So we have a 5 months, almost 2, and almost 4 year old
[04:24] <wallyworld> and an upcoming vasectomy :-)
[04:24] <davecheney> actally no
[04:24] <davecheney> can't add a test for this easily
[04:25] <natefinch> wallyworld: Ironically, I'm the one that wants one, and my wife wants another kid... but i think she's crazy :)
[04:25] <wallyworld> me too :-)
[04:25] <wallyworld> you could always get one secretly
[04:25] <mwhudson> natefinch: my brother had 4 kids at ~2 year intervals
[04:25] <mwhudson> i can't say i recommend it
[04:26] <natefinch> lol
[04:26] <natefinch> yeah, no
[04:26] <natefinch> that's what my wife wants... but I'm quite happy with 3.  4 presents a host of problems we can narrowly avoid with 3
[04:27] <wallyworld> larger car, larger house
[04:27] <natefinch> wallyworld: exactly.  House is 3 bedrooms... the girls are doubling up, and hopefully that'll be fine for a long time... but the other bedroom is pretty small for two kids.
[04:27] <wallyworld> long time = until they turn into teenagers
[04:28] <natefinch> right... at which point the one we trust the most can move into the finished basement
[04:28] <wallyworld> ha, and you will be outside the door with a shotgun
[04:28] <natefinch> so anyway, distro-info has not helped, even after restarting jujud
[04:30] <wallyworld> hmmm
[04:30] <natefinch> yeah, distro-info --all doesn't contain wily
[04:31] <wallyworld> wtf, well that sucks
[04:31] <natefinch> sounds like one of those "someone put up a stream that they shouldn't have" things
[04:31] <wallyworld> i would have thought it woud have
[04:31] <wallyworld> add it by hand to get by for now i guess
[04:32] <natefinch> is there a reason we can't just ignore series we don't understand?   I mean, if we're not even using that series, who cares?
[04:32] <natefinch> remind me where that file is, again?
[04:36] <wallyworld> /usr/share something, i'll check
[04:36] <wallyworld> /usr/share/distroinfo
[04:36] <natefinch> wallyworld: got it, thanks
[04:36] <wallyworld> i think the idea is to stop typos and misconfigured systems
[04:37] <natefinch> it just seems to screw us like clockwork, every 6 months
[04:37] <wallyworld> eg accidentally running a centos series with ubuntu tools
[04:37] <wallyworld> yeah
[04:37] <natefinch> no matter how smart we try to get
[04:38] <wallyworld> waigani: you working on bug 1459047? can you assign yourself and mark in progress?
[04:38] <mup> Bug #1459047: juju upgrade-juju --upload-tools broken on ec2 <juju-core:New> <https://launchpad.net/bugs/1459047>
[04:38] <wallyworld> so we know it's being looked at
[04:40] <waigani> wallyworld: done
[04:40] <wallyworld> tyvm
[04:40] <wallyworld> waigani: helps when we have release meetings each morning
[04:41] <waigani> wallyworld: of course, I'll make a note to keep all that updated
[04:41] <wallyworld> ty
[04:59] <mup> Bug #1459093 was opened: Upgrade fails if there's a series in streams Juju doesn't recognize <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1459093>
[05:52] <dimitern> thumper, hey, still around?
[05:53] <dimitern> menn0, ^^
[06:34] <dimitern> fwereade, hey
[06:35] <dimitern> fwereade, re http://reviews.vapour.ws/r/1777/
[06:36] <dimitern> fwereade, I'd appreciate if you reply to my mail from yesterday and give some rationale around why are we bothering to migrate the remaining state-bound workers to use the API, as it seems it's not generally obvious for a few people
[07:23] <fwereade> dimitern, the resumer worker one?
[07:36] <dimitern> fwereade, yes
[07:37] <fwereade> dimitern, ok, I'm a little bit more concerned that anyone considers it ok for random workers to touch the database directly, but will do
[07:38] <dimitern> fwereade, :) cheers
[08:27] <TheMue> morning o/
[08:27] <TheMue> dimitern: I see there are discussions about the API usage migration of the workers?
[08:34] <dimitern> TheMue, morning
[08:34] <dimitern> TheMue, yeah
[08:35] <thumper> dimitern: I have come back to do a little more
[08:35] <thumper> dimitern: whazzup?
[08:38] <dimitern> thumper, hey, I wanted to ask about your opinion about moving the resumer worker to use the API and run once per apiserver - http://reviews.vapour.ws/r/1777/
[08:39] <thumper> once per apiserver or once per environment?
[08:39] <thumper> I don't see any real reason to have the resumer use the API
[08:39] <thumper> it only ever runs on state server machines
[08:40] <thumper> dimitern: to make it use the api server seems weird to add layers for the sake of layers when it doesn't need it
[08:40] <dimitern> once per apiserver - it applies to all hosted environments AIUI
[08:40] <thumper> well, we only really need one running
[08:41] <thumper> what do we have now?
[08:41] <dimitern> thumper, fwereade can explain better why it's bad to have *any* workers coupled to state.State directly
[08:42] <thumper> dimitern: well... for me it seems like busy work, and something that isn't really needed to be done right now
[08:42] <thumper> why now?
[08:42] <dimitern> thumper, before my PR, it was running in the StateWorker of the machine agent, now I moved it in the method starting per-env workers, but I'll move it to postUpgradeWorker instead
[08:42] <dimitern> thumper, now is as good time as any, and it was planned with lower priority for quite some time
[08:42] <thumper> dimitern: what problem is being fixed by the work?
[08:43] <thumper> dimitern: if there is an active remit to move every worker away from state directly, then I'm fine with it
[08:44] <dimitern> thumper, decoupling the worker from *state.State, improving tests (dropping JujuConnSuite across the board in favor of BaseSuite + mocking), faster and more deterministic tests, the ability to evolve state.State and what the worker needs separately
[08:44] <thumper> sure
[08:44] <mup> Bug #1459148 was opened: azure: juju can't create compute/network optimized instances <juju-core:New> <https://launchpad.net/bugs/1459148>
[08:46] <dimitern> thumper, so can you review that PR with your comments why it's a good thing ? :)
[08:46] <thumper> dimitern: not right now :)
[08:49] <dimitern> thumper, ok, sure
[08:49] <thumper> dimitern: but I will bring it up with menno tomorrow
[08:51] <dimitern> thumper, cheers!
[08:54] <fwereade> thumper, do you recall "api everywhere" as being a major goal about a year ago? having resumer there indicates that we didn't bother to actually finish that work, and at least some people were actively lying about it being complete
[08:55] <fwereade> thumper, and afaics left the door open so that everybody just thought, ehh, direct db access? not so bad, nobody really cares, ehh
[08:55] <thumper> fwereade: IIRC we stopped when the non-state server machine and unit agents were able to not use state
[08:55] <thumper> we agreed that doing all was a time sink at that stage
[08:55] <thumper> I'm not saying it is a worthwhile goal
[08:55] <thumper> just questioning timing
[08:56] <thumper> effort vs. priorities
[08:58] <fwereade> thumper, if that was the case why did we do, eg, firewaller?
[08:58]  * thumper shrugs
[08:58] <thumper> wasn't me :)
[08:58] <fwereade> thumper, because we don't want all our workers running across the db like a gang of drunken monkeys
[08:58] <thumper> heh
[08:58] <thumper> now that is an amusing image
[08:58] <fwereade> thumper, we *will* fuck things up :)
[08:59] <thumper> dude, we screw up all the time
[08:59]  * thumper points fwereade at our bug list
[08:59] <fwereade> thumper, I would like the bulk of our potential fuckups to at least pass through an authorization layer and not to have the power to do literally anything
[08:59] <thumper> sure
[09:00] <thumper> I'm not questioning the work, just the order of work
[09:00] <fwereade> thumper, ok, but we've got people writing new workers that use state now
[09:00] <thumper> oh?
[09:00] <fwereade> thumper, dblogpruner is new, right?
[09:00] <thumper> yeah...
[09:00] <fwereade> thumper, why would we leak the fact that the logs are stored in the db?
[09:01] <fwereade> thumper, the api server can have a "prune logs now please" method
[09:01] <thumper> point taken, I'll bring it up tomorrow
[09:01] <fwereade> thumper, cheers
[09:02] <thumper> actually, I can do better than that
[09:02]  * thumper puts a card on the board
[09:02] <fwereade> thumper, <3
[10:08] <voidspace> dimitern: it seems that with kvm we can supply a template to "uvt-kvm"
[10:08] <voidspace> dimitern: the template is "libvirt domain xml" format
[10:08] <voidspace> dimitern: and that can have a network interfaces section specifying MAC address
[10:08] <voidspace> dimitern: by default, we get the default template (of course)...
[10:08] <dimitern> voidspace, great! have you actually tried if it works ? :)
[10:09] <voidspace> dimitern: (i.e. we're not using the template argument currently)
[10:09] <voidspace> dimitern: no...
[10:09] <voidspace> dimitern: will do
[10:09] <voidspace> dimitern: we'll have to clone the default template and add a network interface definition
[10:10] <voidspace> dimitern: https://libvirt.org/formatdomain.html#elementsNICS
[10:13] <perrito666> good morning
[10:14] <dimitern> voidspace, can't we generate the template always, like with lxc.conf? (based on the default template XML + some text/template tags)
[10:15] <voidspace> dimitern: well, yes
[10:15] <voidspace> dimitern: I meant that initially we'll have to clone the default one
[10:15] <voidspace> dimitern: expressed badly
[10:19] <dimitern> voidspace, sounds good
[10:33] <perrito666> aghh I think the lease singleton is making my tests die :(
[10:35] <fwereade> perrito666, are you running a dummy provider, and are you trying to run your own lease worker?
[10:36] <perrito666> fwereade: none, but I think that the fact of importing lease might be making my test go for 10m until they are killed
[10:37] <fwereade> perrito666, that is unlikely, I think
[10:37] <perrito666> fwereade: well Ill know more in about 10m :p
[10:37] <fwereade> perrito666, -test.timeout 20s
[10:38] <fwereade> the mere fact of importing lease will not cause that
[10:38] <fwereade> perrito666, what are you trying to do with it?
[10:44] <perrito666> fwereade: I stand corrected its something else
[10:44] <perrito666> every outpug log looks different after coffee
[10:45] <perrito666> (and putting my glasses on(
[11:05] <fwereade> perrito666, lol
[13:04]  * TheMue takes a bike-ride to the new potential co-location office now. we'll see how fast I'll be back online ;)
[14:00] <mup> Bug #1459250 was opened: centos 7 is ambiguous in streams <centos> <simplestreams> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1459250>
[14:03] <wwitzel3> ericsnow, natefinch: ping
[14:19] <natefinch> sinzui: https://bugs.launchpad.net/juju-core/+bug/1459093
[14:19] <mup> Bug #1459093: Upgrade fails if there's a series in streams Juju doesn't recognize <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1459093>
[14:20] <natefinch> sinzui: wily isn't in distro-info (at least on trusty)... but I'm guessing someone published a stream for wily
[14:20] <sinzui> :/ How many times does that bug need to be fixed
[14:20] <natefinch> sinzui: just once... we need to stop caring if we see series we don't understand, and just ignore them
[14:20] <natefinch> sinzui: my environment shouldn't care if someone publishes a stream for the series "TOTALLY_INVALID"
[14:21] <sinzui> natefinch, we haven't build willy
[14:21] <sinzui> natefinch, unit tests are run on a machine with a fake series registered in distro-info-data to catch this error
[14:22] <natefinch> sinzui: it's not a problem with something extra in distro-info... it's a problem with someone somewhere mentioning a series that *isn't* in distro-info
[14:22] <sinzui> natefinch, I think wallyworld reported a similar bug/solution.
[14:22] <natefinch> ls
[14:23] <sinzui> natefinch, yep, it is the same long standing issue that juju thinks it has to know the world
[14:54] <mup> Bug #1459288 was opened: TestWriteTokenReplaceExisting fails <ci> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1459288>
[15:00]  * fwereade has just had guests arrive, stopping for now
[15:02] <sinzui> mgz, abentley to either of you have a moment to review https://code.launchpad.net/~sinzui/juju-release-tools/agent-archive/+merge/260321
[15:03] <abentley> sinzui: sure.
[15:05] <abentley> r=me
[15:12] <abentley> sinzui: So I have this bug:https://bugs.launchpad.net/juju-core/+bug/1449208
[15:12] <abentley> sinzui: I know it exists in jes-cli.  I don't have evidence that it exists in master.
[15:12] <sinzui> :/
[15:13] <abentley> Should I create a jes-cli series and target to that?
[15:13] <sinzui> abentley, I don't want to, but I think Lp requires it
[15:13] <abentley> sinzui: I will be the bad guy, then :-)
[15:14]  * sinzui really hates lp bug targeting
[15:16]  * natefinch ^^^^ +1000
[15:17] <mgz> I think we need to sort-of ignore bugs on feature branches
[15:18] <mgz> eg, windows tests are currently borked on jes-cli - but that's kinda their problem
[15:19] <natefinch> or just target all bugs to master and use tags to track branches.  Then we'd actually be able to search all the bugs at once, too.
[15:24] <mup> Bug #1459298 was opened: TestMissingServerFile fails <ci> <test-failure> <juju-core:Incomplete> <juju-core jes-cli:Triaged> <https://launchpad.net/bugs/1459298>
[16:18] <mup> Bug #1278831 changed: debugging first run of install hook is not straight forward <debug-hooks> <juju-core:Triaged> <https://launchpad.net/bugs/1278831>
[16:18] <mup> Bug #1458693 changed: juju-deployer fills up ~/.ssh/known_hosts <juju-core:New> <https://launchpad.net/bugs/1458693>
[16:18] <mup> Bug #1458754 changed: $REMOTE_UNIT not found in relation-list during -joined hook <hooks> <relations> <juju-core:New> <https://launchpad.net/bugs/1458754>
[16:18] <mup> Bug #1459327 was opened: Juju MAAS netwoking with custom bridge inside service <juju-core:New> <https://launchpad.net/bugs/1459327>
[16:18] <mup> Bug #1459337 was opened: UniterSuite setup fails <ci> <intermittent-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1459337>
[17:05] <natefinch> abentley: is there a python equivalent of gofmt that'll fix the linting rules enforced by make lint?  like trailing whitespace, visual indenting, etc?
[17:08] <natefinch> sinzui, mgz: ^^
[17:09] <sinzui> natefinch, no. there are some tools that will do some that that, but nothing that reformats to pep8
[17:10] <natefinch> boo.... manually wrapping lines by hand is uh... not a hugely valuable use of my time
[17:12] <natefinch> especially when it then complains that I don't indent things perfectly.
[17:13] <mgz> natefinch: what editor do you use?
[17:13] <sinzui> natefinch, maybe this will suffice https://pypi.python.org/pypi/autopep8
[17:13] <natefinch> mgz: sublime
[17:14] <mgz> natefinch: top google result is a pep8 autoformat plugin
[17:14] <mgz> for "sublime python format"
[17:15] <natefinch> yeah, just found and installed one... so much better
[17:23] <hatch> using 1.24-beta5.1-trusty-amd64 the deploy command simply hangs is this a known bug?
[17:29] <natefinch> hatch: pretty sure it works fine for me
[17:34] <hatch> natefinch: ok I'm going to restart this machine, see if I can get it working or reproduce reliably
[18:05] <sinzui> abentley, mgz: do either of you have time to review https://code.launchpad.net/~sinzui/juju-ci-tools/more-agents/+merge/260353
[18:28] <abentley> sinzui: looking
[18:31] <abentley> sinzui: r=me
[18:41] <sinzui> thank you abentley
[20:41] <natefinch> ahh yes, the old "you have to update 100 fragile mocks in order for your tests to pass"
[20:41] <natefinch> s/fragile/fragile and incomprehensible/
[20:42] <perrito666> natefinch: ah, welcome to my world
[20:42] <natefinch> perrito666: heh
[20:44] <natefinch> perrito666: I've had central A/C for 5 years... if the house is above 75°F/24°C, everyone's miserable.  Actually, I'm not too bad, but my wife is really uncomfortable, which means I'm uncomfortable
[20:44] <perrito666> oh, so 27 C is a bad temp for you
[20:44] <natefinch> yes
[20:44] <perrito666> now I get it
[20:45] <perrito666> I keep forgetting that you people have blood instead of coolant
[20:45] <natefinch> yep
[20:46] <perrito666> you need more south americanness
[20:47] <natefinch> I agree, but my wife would probably be mad at me if I imported some
[20:47] <natefinch> mental note: upgrade steps get run as-is on your local machine during tests... which means if they delete files off disk... guess what??
[20:48] <perrito666> lol
[20:48] <natefinch> luckily I was just deleting stuff from /var/log/juju ... but still
[21:41] <wallyworld> sinzui: so looking at osversions, i can see why it was done - we just have 13.10 etc for juju series
[21:41] <wallyworld> but we use win8 etc for windows
[21:41] <wallyworld> so i guess for !ubuntu, we need to be more explicit
[21:52] <wallyworld> ericsnow: can i have a trivial review pretty please? http://reviews.vapour.ws/r/1800/
[21:52] <ericsnow> wallyworld: sure
[21:52] <ericsnow> wallyworld: ship it!
[21:53] <wallyworld> ty
[21:53] <wallyworld> ty
[21:58] <sinzui> wallyworld: yeah, that was my expectation.
[21:59] <wallyworld> sinzui: fix landing for 1.24, soon master
[22:35] <thumper> cherylj: regarding the forward port of the vivid/systemd issues, if the branch hasn't significantly changed from the version that landed on the earlier branch, you don't need another review
[22:35] <thumper> just get the bot to merge
[22:35] <thumper> if the branch does have significant changes to the previous, it is useful to say what those where in the description
[22:35] <thumper> this is to smooth the way for fixes to be forward ported
[22:36] <thumper> given that *most* of the time, it is exactly the same fix
[22:36] <thumper> in the newer versions
[23:04] <mup> Bug #1453634 changed: juju upgrage-juju --upload-tools hangs with jes flag <ec2-provider> <upload-tools> <juju-core:Invalid by waigani> <juju-core trunk:Invalid by waigani> <https://launchpad.net/bugs/1453634>
[23:04] <mup> Bug #1459047 changed: juju upgrade-juju --upload-tools broken on ec2 <juju-core:Invalid by waigani> <https://launchpad.net/bugs/1459047>
[23:40] <wallyworld> waigani: i have a bug for your todo list for beta 6 - bug 1441478
[23:40] <mup> Bug #1441478: state: availability zone upgrade fails if containers are present <upgrade-juju> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1441478>
[23:40] <waigani> wallyworld: yay :)
[23:40] <wallyworld> hopefully won't bee too bad
[23:41] <waigani> wallyworld: :), just finishing this one off, then I'll get onto it
[23:41] <wallyworld> ty
[23:44] <menn0_> thumper: http://reviews.vapour.ws/r/1802/ pls
[23:44] <menn0> thumper: easy one :)