[00:10] What would it take to make region a constraint rather than an environments.yaml key? [00:10] Would that even be a worthwhile endevor? [00:21] marcoceppi: not worthwhile IMO === thumper-gym is now known as thumper === axw_ is now known as axw [01:44] thumper: https://codereview.appspot.com/68250046/ [01:44] ta === axw_ is now known as axw [03:03] wallyworld_: I feel much more comfortable now that the existing tests failed :) and it is just that you didn't run them [03:03] yep [03:03] i did say that also in my reply to roger :-) [03:03] davecheney: hey, not sure why hp was failing deploying ubuntu charm [03:03] wallyworld_: ah, missed that [03:03] np :-) [03:03] davecheney: works on amazon and local [03:03] davecheney: what is hp doing different? [03:04] has me very confused [03:09] * thumper pats wallyworld_ on the back for implementing something that I need [03:10] which iiis? [03:11] thumper: what did i implement? [03:11] --description for the supercommand so it works nice with plugins [03:11] ah, that was a while ago [03:11] yeah [03:11] when you did the metadata one I think [03:20] thumper: if you get a chance at some point, i've updated the system key updater to use keymanager https://codereview.appspot.com/68990043 [03:21] kk [03:21] * thumper is getting sidetracked by other issues... [03:21] * thumper must get back on track [03:21] * thumper files bugs [03:22] thumper: I guess it's best to just wait for cross environment relations? [03:23] marcoceppi: ENOCONTEXT [03:23] thumper: re: regions as constraints [03:23] marcoceppi: yes [04:09] thumper: ffs. found the local provider tools issue. host machine is trusty, charm is precise, so looks for different tools [04:10] gotta think about the least invasive way to fix [04:40] wallyworld_: ah... [04:40] wallyworld_: interesting [04:40] wallyworld_: hang on [04:40] wallyworld_: trusty is only the machine 0 [04:41] machine 1 which has the charm is precise [04:41] yep [04:41] the wrong location is being used somehow [04:41] ok [04:42] the UA on machine 1 talks to state server on machine 0 [04:42] the state server looks in its data dir for tools [04:42] and only finds trusty [04:53] wallyworld_, thumper: I merged trunk into a branch and reproposed... now the changes from trunk are coming through in Rietveld. LP has the correct diff. Anyway to fix Rietveld's diff? [04:53] axw_: nope :-( [04:53] shiteveld sucks [04:53] axw_: delete the merge proposal in LP [04:53] launchpad rocks [04:53] hrm, I may have been impatient anyway [04:53] and start again [04:54] it might be okay. yeah I thought that'd be the answer :\ [04:54] same thing happened to me today [04:54] with my system ssh key upgrader branch [04:55] ah it's okay, I was looking at diff-from-previous which adds things as expected... PEBKAC [05:20] * thumper looks at https://code.launchpad.net/~wallyworld/juju-core/system-sshkey-upgrader/+merge/208277 because reitveld is dumb at trunk merges [05:20] yes it is :-( [05:21] wallyworld_: can't see the trivial test I wanted... [05:21] oh, did i forget [05:21] let me check the comment again [05:22] thumper: all i did in auth keys was to add 2 constants [05:23] * thumper demands tests [05:23] that's all it does now [05:23] what about later? [05:23] the test is trivial to write [05:23] sigh. the code was already in trunk [05:23] I know... [05:23] but you made it public [05:24] public functions should have tests [05:24] * thumper pays wallyworld_ back for demanding tests [05:24] * thumper is just helping really [05:24] thumper: i didn't write any of that code [05:24] but ok [05:24] call it review creep [05:24] it earns you brownies [05:24] * wallyworld_ sighs again [05:24] yeah yeah [05:45] thumper: finally got the tests done... new CL for worker/rsyslog: https://codereview.appspot.com/68930045/ === thumper is now known as thumper-back-for === thumper-back-for is now known as thumper-afk [06:23] * thumper-afk back for meeting later [06:32] wallyworld_: I now have an LGTM for https://codereview.appspot.com/68930045/, but not for its prereq. If you have a spare few minutes, would you mind taking a look at https://codereview.appspot.com/69000043/? [06:32] basically just deleting a whole lot of code :) [06:33] if you're too busy it can wait till tomorrow [06:43] looking === rvba` is now known as rvba [08:01] mornin' all === rogpeppe1 is now known as rogpeppe [08:53] hazmat: how's your super sexy juju lxc fast provisioning coming along? [09:25] dimitern, do you have a moment? [09:43] mattyw, sure [09:43] about 15m to the weekly meeting === thumper-afk is now known as thumper [09:50] ev: o/ [09:50] ev: I'm takeing hazmat's fast lxc and putting it in trunk [09:51] expect some good stuff over the next few weeks [09:58] thumper: you're my hero [10:00] fwereade, mgz, meeting? === psivaa-afk is now known as psivaa [12:09] dstroppa: around again, poke me if you have more StopInstances questions [12:11] thanks mgz, I've made some changes, running tests now [12:12] back to the other issue: I've update goose, but now get this http://paste.ubuntu.com/7004730/ [12:12] running on precise [12:17] dstroppa: but `go build ./...` is clean? [12:19] mgz: same error [12:21] dstroppa: but no more details? if the branch doesn't build you want to get a proper error out of the go compiler [12:22] mgz: this is the only output I get http://paste.ubuntu.com/7004758/ [12:22] dstroppa: as a first check, you can run `godeps -u dependencies.tsv` using lp:godeps which will tell you about other goosey problems [12:26] dstroppa: ugh, I can't actually remember what the cause of things like that is [12:27] rogpeppe: ^if go build just dies with a kill signal, what's going on? [12:27] OOM I think was one of them [12:45] mgz: updated all dependencies, still same error [12:45] I'm running in a vagrant box with 512MB [12:45] ...it could be the OOM then [12:46] give it another 512 [12:55] mgz: yup, it was OOM [12:55] bot was down it should now be up again [12:55] (if people have things they need to land) [12:55] looked like a mongo wedge [12:56] dstroppa: ace [12:57] dstroppa: the other thing we should do today is land the storage branch [12:58] mgz: cool [12:58] it probably wants a bump in dependencies.tsv for the latest gojoyent, retesting, then we can go [13:07] ev, its not polished for end-users, entirely undocumented, and requiring some manual setup.. http://github.com/kapilt/juju-lxc its what i'm using daily... the improvements will land into core though [13:08] hazmat: wooohoo! [13:14] rogpeppe, time for a quick question? [13:14] mattyw: sure [13:15] rogpeppe, my add/remove user branch - https://codereview.appspot.com/61620043/ - I hadn't actually checked that the caller had permission to add/remove the user (using a common.GetAuthFunc) [13:16] now that I am - what should the rules be? I'm tempted for now to just let everyone add/remove [13:16] (for now basically meaning until we start implementing roles in the next couple of weeks) [13:16] mattyw: i think that's fine for the time being - we don't have any roles yet [13:17] rogpeppe, cool! so I'll just always return true in my auth func [13:17] mattyw: seems fine (i think there's a helper function for that actually - it might be called AuthAlways or something) [13:18] rogpeppe, I'll take a look - thanks again [13:36] mgz: storage branch updated, retested and ready to go [13:37] dstroppa: then, set commit message and I can mark approved (or just use `bzr rv-submit` yourself) === marcoceppi_ is now known as marcoceppi [13:44] mgz: set a commit message, got an "unknown command" when running bzr rv-submit [14:13] anyone know what "bad record MAC" is about as a failure on the bot? [14:13] I didn't find an lp bug [14:13] 's mongo related [14:14] mgz: i *think* that's a mongo bug [14:14] mgz: and might be fixed in the next mongo version [14:17] rogpeppe: ta, I think I'll file a juju-core bug for refernce [14:17] rogpeppe, mgz, does juju reject unsigned image json? Can devs build their own os images, generate the streams, and juju will accept them? [14:17] sinzui: i'm not sure, but i think it should do [14:17] sinzui: but i'm not sure what we use for the root key [14:18] sinzui: for checking the sig validity [14:18] sinzui: they can provide their own image and streams, we have places where they can set alternatives to streams.canonical.com [14:18] I think there is one implementation of simplestreams, so the behaviour of os images should match the tool behaviour [14:18] mgz: do you know how it verifies self-generated streams? [14:19] mgz, that is exactly what some canonical people are testing. They think they need sjson [14:22] there's a difference between unsigned .json (which we just accept) and .sjson - I'm not how we'd verify self-signed .sjson [14:25] mgz: isn't that a security hole? [14:26] not really, if you're uploading your own simplestreams data to a personal container in the cloud storage, [14:27] mgz: or... i suppose whether it's signed or not is encoded in whether the configured URL ends in ".sjson" or not [14:27] you're just relying on the cloud and secure conections to make sure what you put there is what you end up using [14:27] rogpeppe: it's a little more involved that that [14:28] the code has a flag that enables a fallback url lookup if the .sjson at a given location doesn't exist [14:28] which is not set in all cases [14:29] mgz: is that in the environ config ? [14:29] so, it goes something like, .sjson at configured location, .json at configured location, .sjson at cloud default, .sjson at streams.canonical.com I believe [14:29] ..but probably with even more steps [14:30] mgz: where does the "configured location" come from? [14:30] mgz: is it tools-metadata-url ? [14:30] tools-metadata-url in environments.yaml for instance === frankban_ is now known as frankban [14:31] mgz: ah, so we're rely on DNS being secure? [14:31] s/rely/relying/ [14:32] yeah, and https, and the cloud itself, if the user sets that as config [14:32] mgz, rogpeppe We allow people to setup their private clouds...they should know how to make their cloud secure [14:33] mgz, sinzui: i was actually thinking of the default case, not the custom-cloud case [14:33] I would not swear by it, but the true default case shouldn't do the fallback to looking for .json in any of our base locations [14:33] own image in public cloud? I think that is push to bucket with acls for yourself and friends [14:34] mgz: ah, so the only way to have it actually secure is to use our default? [14:35] I think so, I'm not sure how we'd add a new trusted signing key for self-signed simplestreams at present [14:35] wallyworld may actually have a way though [15:07] dstroppa: ah, you're back on [15:07] dstroppa: you need to merge trunk to resolve conflicts [15:10] mgz: doing it now [15:35] dstroppa: one more thing, you're still using loggo from launchpad.net [15:35] you need to switch to the github import [15:38] mgz: I can see the github import http://bazaar.launchpad.net/~dstroppa/juju-core/joyent-provider-storage/view/head:/provider/joyent/provider.go === Ursinha is now known as Ursinha-afk [15:43] dstroppa: oh, I probably forgot to pull gojoyent [15:47] dstroppa: flagged for the bot to land [15:48] mgz: cool [15:48] dstroppa: you need to send a message to juju-dev mailing list telling everyone to get the gojoyent library as a new dep [15:48] mgz: will do === Ursinha-afk is now known as Ursinha [15:53] dstroppa: though, the bot hates me at the moment, so it may not land straight away [15:55] * fwereade is going to be back for most of the evening, but needs to stop for a bit now; I have a couple of reviews up that I'd greatly appreciate opinions on [16:06] natefinch: ping [16:08] rogpeppe: pong [16:08] natefinch: i was looking at the replicaset tests, and it seems they assume that replSetGetStatus always returns the members in id order [16:08] natefinch: do you know that's guaranteed? [16:09] rogpeppe: I don't remember [16:10] natefinch: i wonder if it might be worth sorting it just to make sure [16:11] rogpeppe: certainly couldn't hurt in the tests, and I don't think anywhere else relies on the order [16:12] natefinch: actually, looking at the mongo server code, it does seem to sort it [16:12] natefinch: but i agree, i won't do any harm [16:12] s/i wo/it wo/ [16:15] fwereade, do you want to schedule a hangout to discuss the owner-tag juju status branch - or shall we just do it on irc? [16:29] rogpeppe: do you have some time to talk about ensure mongo server? I'm kinda thrashing because I don't quite understand what I'm supposed to be writing. [16:30] natefinch: sure. give me a moment to make this test pass again and we'll chat [16:30] rogpeppe: cool [16:33] natefinch: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig?authuser=1 [16:49] mattyw, I think I'll be meeting with casey about charm store stuff tomorrow -- if you'll be there, can we maybe piggyback it on that? === vds` is now known as vds [17:58] arosales: https://bugs.launchpad.net/juju-core/+bug/1285803 [17:59] <_mup_> Bug #1285803: [Joyent Provider] metadata mismatch when testing again Joyent Public Cloud [17:59] dstroppa: thanks. I'll confirm this is not the image or the stream data [18:03] dstroppa: your added dependencies.tsv file has spaces rather than tabs, fix that and I can try landing again [18:08] mgz: just pushed r1983 [18:13] dstroppa: reflagged [18:34] Hi devs, I see we are again announcing the juju-restore plugin. It says it restores a juju backup. How would someone make a backup? there is no juju-backup installed [18:35] sinzui: juju-backup does *exist*... [18:36] sinzui: where's your packaging branch live atm? [18:36] but no one added it to be installed. I see the restore is there [18:36] I can add that and james can pickup my changes [18:36] that sounds like the right thing. [18:36] Do I want to do that now and delay the release? [18:37] well I have some release notes to write so as long and I an writing , I can let CI tell me it works [18:37] I think so. [18:50] *** Test killed: ran too long (10m0s). [18:50] FAIL launchpad.net/juju-core/worker/upgrader 600.014s [18:50] bot hates me, one more time as I go... [19:01] g'night all [19:02] g/night rogpeppe [19:09] hmm, since juju-backup is not a go plugin, installing it is more difficult than I imagined [19:33] sinzui: sorry, I actually haven't ever used juju plugins. [19:35] natefinch, np. I just assumed it was a go plugin like juju-restore and juju-metadata. The installation is simple but different from everything else in the rules file [19:35] I was stressing because I want this packaging change included in the build and test that just started [20:01] marcoceppi: around? [20:01] ahasenack: otp [20:01] ok [20:02] marcoceppi: for posterity: http://pastebin.ubuntu.com/7006888/ [20:02] def setup(self, timeout=600): [20:02] (...) [20:02] with timeout(timeout): [20:02] that can't work, right? :) [20:02] fwereade: you up? [20:02] ahasenack: no, I don't think so [20:03] ahasenack: lookup confusion [20:03] thumper: he said he was going to be away in the afternoon and around in the evening. It's evening there, but not sure exactly what hours he was going to be around [20:03] natefinch: thanks [20:03] I'm about to go mobile and head into town [20:03] will work from there while the car gets serviced [20:04] marcoceppi: fixed in 1.3.1, nm [20:04] ahasenack: yeah, that was patched really quickly [20:05] marcoceppi: :) [20:05] unfortunately not before it was released :\ [21:00] fwereade: around now? === BradCrittenden is now known as bac === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha