[00:01] sinzui: the first comment on that bug - i don't think juju needs to change since it already generates metadata for just one stream at a time, leaving the other stream metadata untouched [00:25] wallyworld_, does implementing option 3 risk releasing beta1 tomorrow? [00:25] sinzui: i'll have a fix asap [00:25] wallyworld_, As much as I don't want to write hack, I can do it in a 3 hours [00:25] sinzui: the hack will be the backup plan? [00:26] but i will have juju changed today [00:26] promise :-) [00:26] wallyworld_, it allows my to release, then worry that juju will want to do something different next week [00:26] wallyworld_, I like your promises, but I don't want you to rush, stress, loose sleep [00:27] i'll be fine, we're almost there [00:27] i'll have it done b the time you SOD [00:27] okay, thank you, but if you discover blocker, remember we have a backup plan [00:27] yep, good to know :-) [00:27] just finishing 1 other bug, will get straight on to it soon [00:37] is there something i can do to prevent this (see agent-state-info on machine 3)? http://pastebin.ubuntu.com/8859275/ [00:59] tvansteenburgh: that will be fixed in 1.21 beta1 [01:00] wallyworld_: \o/ thanks [01:00] we expect to release the beta by early next week [01:00] that's great news, i was about to ask :) [01:00] :-) [01:00] there's also a lot of other network fixes for maas [01:01] well juju/maas [01:23] tvansteenburgh: you can delete the default VPC in your region if you don't need it; you can't undo that (without AWS support's help) [01:23] that should stop the error from occurring [01:42] axw: when you have a moment :-) http://reviews.vapour.ws/r/369/ [01:50] thanks :-) [02:00] axw: thanks for the tip, although i probably can't/shouldn't do that since these environments are owned by sinzui and co. [02:11] right, probably not then ;) [02:38] axw: i'm off to lunch, so no hurry, but review appreciated http://reviews.vapour.ws/r/370/ [02:42] wallyworld_: sure, enjoy === axw_ is now known as axw [03:51] axw: when you have a minute could you take a look at http://reviews.vapour.ws/r/342/? It's a little guy. [03:55] ericsnow: sure [03:55] axw: thanks [04:10] ericsnow: done [04:14] axw: with that backups is now completely switched over to gridfs :) [04:14] ericsnow: awesome :) [04:31] ericsnow: you backporting to 1.21? [04:31] wallyworld_: planning on it [04:32] ericsnow: awesome. curtis will be doing a beta build tomorrow [04:32] wallyworld_: I guess I'm planning on doing it tonight! :) [04:32] \o/ [04:32] ericsnow: or we can [04:33] once it lands, we'll backport [04:33] wallyworld_: well, there's more than one patch that needs backporting [04:33] ericsnow: in that case, don't worry, it can wait [04:33] wallyworld_: k [04:33] it will be a bit of risk [04:34] ericsnow: just in case, can you email be the rev numbers that would need merging [04:34] wallyworld_: will do (shouldn't be more than a handful [04:34] ok, ta === kadams54 is now known as kadams54-away === urulama__ is now known as urulama [06:05] wallyworld_: I've emailed you those rev numbers (3 of them) [06:06] thanks ericsnow :-) [06:06] wallyworld_: plus the one I'm commiting right now (to master) [06:06] righto [06:06] wallyworld_: you think I should hold off on backporting them? [06:07] ericsnow: well, it's really late for you isn't it [06:07] wallyworld_: sort of :) [06:07] so, we'll backport if needed, you go get some sleep [06:07] wallyworld_: k [06:08] have a good weekend [06:08] wallyworld_: also, are we okay to land http://reviews.vapour.ws/r/371/? (add .reviewboardrc to the 1.20 branch) [06:08] can't see why not [06:08] wallyworld_: k [06:10] wallyworld_: FYI, we've yet to land the restore side of backups (and we're cutting it close) [06:11] ericsnow: i was hoping to be divorced from storage, but if it's not all there, we can wait [06:12] wallyworld_: I meant the replacement for the juju restore CLI plugin (not storage) [06:13] ah, right, yeah that one will have to wait [06:13] wallyworld_: wait for what? [06:13] 1.22 [06:14] ideally we'll have a week to fully test 1.21 beta before release, which is next friday [06:14] wallyworld_: so does that mean we should yank the new backups (at least the CLI for it)? [06:15] wallyworld_: they kind of go together [06:15] yeah, i'm not across the state of play with that stuff [06:15] wallyworld_: okay, I'll follow up with Nate tomorrow [06:15] ta, but i imagine we'd want to revert the cli [06:16] keep curtis in the loop also [06:16] as he will be pulling th trigger on the release [06:19] wallyworld_: got it [06:19] ty [06:20] wallyworld_: have a good weekend :) === urulama is now known as urulama__|home| [07:46] does anyone know if the "format" field in metadata.yaml still has any relevance to anything? [07:46] fwereade: ^ [07:47] rogpeppe: beware format 0 charms [07:47] davecheney: there are none [07:47] davecheney: AFAICS - i downloaded all the charms in the charm store [07:48] davecheney: hi, BTW! [07:48] davecheney: do you know the difference between format 1 and format 2 ? [07:49] davecheney: the only charms that i can find that explicitly mention format specify 2, which is different from our default. but we don't seem to have any logic (in the charm package anyway) that cares one way or another [07:50] rogpeppe, davecheney: the format stuff was a long long time ago, and I thought all references to it had been purged [07:51] fwereade: there are still remnants in the charm package [07:51] rogpeppe, davecheney: I can't remember exactly what it did -- some subtle change in hook tool behaviour [07:51] rogpeppe, I think it's safe to ignore them [07:51] rogpeppe, the code that would have been triggering on them does not exist [07:51] fwereade: i'm just writing a GetYAML method so we can marshal metadata as yaml (finally!) and i'm just making sure that I can always omit the format field. [07:52] * fwereade cheers heartily at rogpeppe [07:52] rogpeppe, that sgtm [07:52] fwereade: cool [07:53] fwereade: this means that soon you'll be able to programmatically generate charms in tests and produce their yaml metadata, which i think you might find quite useful :) [07:54] rogpeppe, that is why I'm cheering :) [07:54] fwereade: :) [08:00] rogpeppe: i think we had this discussion in august 2012 [08:01] and determined at the time we'd expunged them all [08:01] * rogpeppe forgets most things [08:01] from memory, i think the charm format affected the default output format of charm hooks ? [08:01] and let me just say, "good riddence" [08:01] davecheney, that sounds pretty likely [08:02] davecheney, yeah :) [08:02] morning folks === liam_ is now known as Guest18751 [08:52] anyone fancy a little review? https://github.com/juju/charm/pull/75 [08:55] morning [09:07] morning TheMue [09:08] alexisb: hey, still in Europe? [09:09] I dont normally get to say that to you [09:09] yes I am in paris [09:09] alexisb: or is you inner clock not yet adjusted back to home? ;) [09:10] alexisb: ah, ok, I thought you were already on your flight back === liam_ is now known as Guest78079 [09:51] fwereade: https://github.com/juju/charm/pull/75 [10:23] fwereade, are you around? [10:24] fwereade: i'm not sure what you mean by making the marshaling explicit [10:25] fwereade: do you mean the field names? [10:26] rogpeppe, yeah [10:26] fwereade: why is that better? we rely on the default lower casing everywhere else? [10:26] s/\?$// [10:27] fwereade: and the tests ensure that it's working correctly [10:27] rogpeppe, (1) we try not to everywhere else [10:27] rogpeppe, (2) it's hard to make those tests good [10:27] rogpeppe, unless we do explicit checks of what gets written out, which have their own problems [10:28] fwereade: the tests test round-tripping, which seems like a good-enough test to me [10:28] rogpeppe, roundtrip tests don't detect marshalling *changes* though [10:28] fwereade: yeah, i think they will [10:28] fwereade: we read in with the standard ReadMeta, and check that when marshaled, and read back, we get the same thing [10:29] fwereade: so if the marshaling semantics change (e.g. to not lower case the name) the test will fail [10:31] fwereade: for example, if i change the "Categories" tag so that the name is "Categories", the test fails [10:31] rogpeppe, doesn't that depend on a chain of inference across multiple tests and implementations? I'd rather just have it 100% obvious how something's going to marshal [10:32] rogpeppe, assuming readmeta works and the readmeta test works and this test uses readmeta... [10:32] rogpeppe, vs "that's how it marshals, done" [10:32] * fwereade has to go again anyway [10:33] fwereade: ok, i'll add explicit names, no big deal [10:34] fwereade: though everything would break if yaml didn't lower-case as it marshaled (i actually don't like that behaviour, as it's doesn't fit with encoding/json, but i think it's reasonable to rely on) [10:35] fwereade: and the same testing issue applies whether i make the names explicit or not. [10:36] rogpeppe, thanks -- fwiw I've caught at least one proposed fieldname change that would have broken stuff subtly, I'd rather just make that mistake harder across the board [10:37] rogpeppe, granted, but it's that fieldname changes don't *always* trigger hey-changing-marshalling in people's brains [10:37] rogpeppe, this means that marshalling changes must be made explicitly, and will be seen to be explicit in review [10:37] fwereade: at some point, i plan to implement a backward-compatibility checker that can ensure this kind of stuff automatically [10:37] rogpeppe, that sounds awesome [10:38] rogpeppe, in the meantime, be so kind as to indulge my paranoia ;) [10:38] fwereade: will do [10:38] fwereade: the idea is that you run all the tests, check what gets marshaled/unmarshaled, and that gives you your list of stuff that needs to be maintained correctly. [11:06] jam, wallyworld_, axw: could u plz cast ur eyes over http://reviews.vapour.ws/r/357/ when u get a chance. this should cater for recomendations based on hardware and user preference [11:31] this needs a review. it's a fix for one of the bugs that needs to be sorted for 1.21 beta1. Turns out it's a long-standing issue. http://reviews.vapour.ws/r/377/ [12:12] here's a tiny PR in the charm package, if anyone wants to take a look: https://github.com/juju/charm/pull/76 [12:18] rogpeppe: will do [12:18] TheMue: ta! [12:21] rogpeppe: lgtm [12:21] TheMue: ta! [12:21] yw [13:06] anyone know where fwreade is? [13:06] wallyworld_, I am looking at him [13:06] alexisb: ah, in that case i really need to talk to him [13:06] fwereade: !! [13:07] a couple of things, could you please look at http://reviews.vapour.ws/r/377/ [13:07] we need to land this for 1.21 [13:07] wallyworld_, ok, looking [13:08] it looks ok, but i have a coupleof concerns, bt may be ok [13:10] wallyworld_, I think that LGTM, but what are the concerns? [13:10] fwereade: what happens if someone changes the number of sub ords after a relation is added [13:10] then it could become invalid [13:11] wallyworld_, don't understand the question [13:11] wallyworld_, a service can't change its subordinacy [13:11] fwereade: i had a couple brief other questions, quick chat? [13:11] or you may be busy [13:12] wallyworld_, in a sprint room, private irc if you don't want to pollute here? [13:12] wallyworld_, happy to talk ofc [13:12] wallyworld_, just not convenient to do so out loud [13:12] wallyworld_, also my connection is rather spotty === urulama__|home| is now known as urulama [13:54] perrito666: thanks for the follow up, dimitern and ericsnow got me sorted. I should have sent un-ping ;) [14:00] np [14:00] you can thank fwereade that told me you where looking for me, he told it to me after 3 beers, but the information persisted nevertheless [14:04] perrito666: is nate around? [14:20] wallyworld_: there he is [14:20] anyone can review a trivial patch to fix bug 1307677? http://reviews.vapour.ws/r/380/diff/ [14:20] Bug #1307677: juju tries to use lxcbr0 when local provider is configured with kvm containers

[14:20] perrito666: tis ok, i was just going to ask for a branch to be backported, but i've just done it [14:23] cmars, TheMue, as OCR, can you have a look? ^^ [14:23] wallyworld_: uh, I should postpone answering to you more often [14:25] indeed :-) [14:25] fwereade: tap me next sprint and i'll get ya a beer [14:26] perrito666: same to you *hattip* [14:26] thanks wallyworld_ ! [14:27] dimitern: np, sorry about brief comments, beena long day [14:27] is this for 1.21 also? [14:27] wallyworld_, yeah [14:27] dimitern: *click* [14:28] great, really happy to see these network issues get fixed [14:29] natefinch: hey [14:30] or perrito666 [14:32] yo [14:33] hey nate [14:33] for 1.21 [14:33] dimitern: you've got a review [14:33] TheMue, thanks! [14:33] i landed menno's fix for bug 1382751 [14:33] dimitern: yw [14:33] Bug #1382751: non subordinate container scoped relations broken

[14:33] pr 1075 [14:33] i backported to 1.21 [14:33] and tried to land in pr 1077 [14:34] but [14:34] there was test failure, due to a missing file http://juju-ci.vapour.ws:8080/job/github-merge-juju/1229/console [14:34] i'm totally buggered, after 12:30am here [14:34] could you possibly take a look and fix the issue and land? [14:34] it should be small and easy hopefully given it's anded in master already [14:35] wallyworld_: sure [14:35] tyvm [14:35] the goal is to get 1.21 beta blessed today [14:40] wallyworld_: seems likely something changed between 1.21's charm.v4 revision and master's charm.v4 revision [14:41] ah could be, charm.v4 has changed, yes === liam_ is now known as Guest54104 [14:47] natefinch: maybe also poke wayne about bug 1361316 [14:47] Bug #1361316: juju status panic if state conn is shutdown || closing.

[14:47] should be a one line fix [14:47] wallyworld_: yep, I'll ping him. he was going to start looking at it yesterday, I'll make sure he's just doing the easy fix and not the hard fix :) [14:48] wwitzel3: ^ [14:48] yeah, juju status is messed up [14:48] even with err != nil, you are expected to still print partial status [14:48] anyone know that state of bug 1381619 [14:48] Bug #1381619: Failed to destroy-environment when node is in commissioning or new state

[14:49] comments on the bug made me think that the fix was well understood [14:49] wallyworld_, voidspace started on that yesterday IIRC [14:49] rogpeppe: You just changed something in charm.v4 about testing and charm repos... we're trying to backport a change from master to 1.21 and it's getting this error: ... Panic: open /home/ubuntu/juju-core_1.21-beta1/src/gopkg.in/juju/charm.v4/testing/repo/quantal/logging-principal/metadata.yaml: no such file or directory (PC=0x4144D6) [14:49] hopefully will be done today as it's marked critical for 1.21 :-) [14:50] anyways, gotta sleep, good luck with final bug fixes [14:50] natefinch: looks like you've got the wrong dependencies [14:51] yay windows is fun [14:51] natefinch: or... do you need the new changes in the charm package? [14:51] rogpeppe: well, so 1.21 uses charm.v4 from before your latest change... [14:51] rogpeppe: that or we make the ported fix work with charm.v4 from before your change [14:51] natefinch: if that's the case, then how could my change in charm.v4 affect it? [14:51] natefinch: ok, I can add the status check and put up a review [14:52] natefinch: i think you'll have to do that [14:52] rogpeppe: the fix was made to master after your change [14:52] natefinch: that's part of the backport [14:52] rogpeppe: right, so my question is - what's different? [14:52] wwitzel3: cool [14:53] natefinch: we moved the testing charms repo from charm.v4 to juju-core [14:53] natefinch: but... [14:53] natefinch: that error message looks like you haven't updated the charm.v4 package [14:54] rogpeppe: right, I'm just concerned that if we update the charm.v4 revision that 1.21 uses, that it'll break a whole lot more stuff [14:54] natefinch: because charm.v4/testing/repo/quantal *should* exist in the old charm.v4 package [14:54] natefinch: yes, it will. don't do that. [14:54] oh hmm [14:54] ok, good, so that's what I assumed [14:55] natefinch: it's possible that the logging-principal test charm was added recently [14:55] https://github.com/juju/juju/pull/1077/files [14:55] it was added in this PR [14:55] natefinch: what version of charm.v4 is being used? [14:55] rogpeppe: f97c8d630e45651f7b39ce352dd7329082f134c4 [14:56] natefinch: right, that's your problem [15:00] well, so, I'm not sure how to fix this. If updating the charm.v4 revision will break a bunch of stuff... but this test won't work in 1.21 because charm.v4 at that revision expects the testcharm to be under its own testing/repo directory [15:00] natefinch: i see the issue [15:01] It seems like the only fix is to update 1.21's dependencies to use charm.v4 with your change [15:01] natefinch: and this is also a reason that the changes we've made in charm.v4 are good - it will prevent things like this from happening again [15:01] yes definitely [15:01] natefinch: yes [15:01] and then fix whatever else falls out of that [15:02] natefinch: those changes were sweeping but pretty much automatics [15:02] s/cs$/c/ [15:02] k [15:02] natefinch: and the compiler will tell you if you've gotten it wrong [15:02] backporting is such fun [15:03] what's doubly aggravating is that this is just for the test. The actual production code is fine. [15:03] (in theory) [15:03] well, I'm glad we made the fix so it won't happen again... too bad we hit it one last time though [15:08] natefinch: standup? [15:33] sinzui: FYI, the restore side of backups has not landed for 1.21, which renders the rest of the new backups code kind of pointless for 1.21 [15:34] sinzui: I'm planning on getting a change into 1.21 that simply removes the new backups CLI but leaves the rest of the backups code intact (to lessen the risk of removing so much) [15:34] sinzui: that patch should be up in a little bit [15:35] natefinch: http://reviews.vapour.ws/r/382/ fix for lp:1361316 [15:38] ericsnow, thank you [15:40] also wallyworld_ if you're still around - http://reviews.vapour.ws/r/382/ [15:41] natefinch, can you organise an effort to backport the fix for bug 1382751 to beta1 (1.21 branch)? It may be in progress already [15:41] Bug #1382751: non subordinate container scoped relations broken

[15:42] sinzui: yeah, it's in progress by me ;) [15:42] sinzui: just updated the bug to reflect that [15:43] you rock natefinch [15:43] someday I'll tell the story of changing the keys on my keyboard so the bottom row spelled out "NATEROCKS" :) [15:43] ok, well, actually, that's the whole story [15:46] :) [15:47] thanks for the review TheMue [15:48] wwitzel3: yw [15:49] I just got an email from Amazon trying to get me to pay $99 to stick a device in my home that will listen to everyting in my house and send all that data to them ... [15:49] I feel like they should pay me for that [15:49] hah [15:49] wwitzel3: what's the device called? [15:49] I've not heard of that [15:49] Amazon Echo .. [15:49] wwitzel3: the NSA probably did that for you for free [15:50] if it was April .. I would of thought it was a joke [15:50] http://www.amazon.com/oc/echo [15:50] interesting [15:51] I saw a thing about that yesterday. It seems interesting, but don't we all have something like that in our pockets already? I guess not with a halfway decent speaker [15:51] see, the NSA did it wrong, all they needed to do was has a nice landing page and charge people for PRISM and it would of been a hit [15:51] haha [15:52] honestly, the main problem with this thing is that it's audio-only. You now how many times I'm going to listen to it read out a wikipedia page? [15:52] :-) [15:53] natefinch: though it is probably more effective than when your friends read a wikipedia page off their phone, they always leave out the citation needed part :D [15:53] axw: ping [15:54] haha [15:54] axw: although I really doubt you're around [15:55] voidspace: it is like 5am saturday morning, who isn't up (still) then? ;) [15:55] voidspace: since you are OCR today, mind looking at http://reviews.vapour.ws/r/382/ [15:56] ah, am I? [15:56] voidspace: you and fwereade I believe [15:56] sinzui, natefinch: 1.21 backups CLI removal patch: http://reviews.vapour.ws/r/383/ [15:56] wwitzel3: you're looking at the wrong friday I think... [15:56] voidspace: probably [15:56] voidspace: will you look anyway *eyebat* [15:57] heh [15:57] wwitzel3: cmars and TheMue are OCR [15:57] wwitzel3: seeing as I'm very unlikely to get this high priority bug completed anyway *sigh* [15:57] wwitzel3: I think I know where in the code to fix it at any rate [15:57] wwitzel3: you got a ship it from TheMue [15:57] voidspace: which are you working on? [15:57] wwitzel3: there's even a comment from axw predicting that there would be a problem with the code... [15:57] natefinch: don't we still need two? [15:57] yeah [15:58] wwitzel3: bug #1381619 [15:58] Bug #1381619: Failed to destroy-environment when node is in commissioning or new state

[15:58] wwitzel3: no? [15:58] oh, I was still under the impression we needed two LGTM/Ship It on reviews, ok :) [15:59] wwitzel3: have you seen how RB renders that diff? [15:59] ericsnow: ^^ [15:59] wwitzel3: I don't think we've needed 2 LGTMs since before we hired you :) [15:59] anyway LGTM *sigh* [15:59] wwitzel3: couldn't you just remove registering the command, whilst leaving the rest of the code in there? [16:00] ericsnow: yeah, that's what I was thinking ^ [16:00] voidspace: huh? [16:00] wwitzel3: I think he keeps typing you instead of ericsnow [16:00] wwitzel3: basically, only do the change in cmd/juju/main.go [16:00] natefinch: when I entered whoever induced me, which I believe was mgz said that 1 for trivial changes 2 for anything importan [16:00] t [16:00] oh [16:00] voidspace: what? [16:01] is it ericsnow who asked for the review [16:01] wwitzel3: no, you asked for a review on 383 [16:01] oops [16:01] wrong thing [16:01] wwitzel3: which removed backups [16:01] haha [16:01] 383 is eric's code [16:01] ah, ok [16:01] voidspace: http://reviews.vapour.ws/r/382/ sorry .. but I apparently don't need your review anyway :P [16:01] ericsnow: for 383... couldn't you just remove registering the command and leave everything else in place? [16:02] wwitzel3: hah ok :-) [16:02] voidspace: too easy [16:02] ericsnow: :-) [16:02] ericsnow: if the code is good, and it's tested, why not leave it in place [16:03] voidspace: good point; it hadn't crossed my mind [16:07] fwereade, you got 30 seconds? [16:07] mattyw, yeah, more or less :) [16:10] voidspace: yeah, that makes for a much simpler change :) [16:11] ericsnow: +1 [16:11] natefinch: could you give me a ship-it? [16:12] ericsnow: done [16:12] natefinch: thanks [16:12] ericsnow: just make sure all the tests still pass [16:12] natefinch: they do [16:12]