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