[00:34] thumper: ? [01:42] wallyworld_: sorry [01:45] thumper: np, chat now? [01:45] sure [01:45] anastasiamac: re http://aws.amazon.com/ec2/pricing/, I was looking at spot instances - I see it says unspecified in the on-demand section as you said [01:45] weird [01:50] axw: yes, if you look at sao paolo region, it shriks the list of supported instances [01:50] axw: i deduced that frankfurt *could* have the types marked as **unspecified** [01:51] axw: but m happy to let it rest for now [01:52] axw: :D it's amazing what an effect a small change can have :)) [01:52] :) [01:56] could someone spare me a review on http://reviews.vapour.ws/r/1094/ [01:56] it un-reverts an earlier patch and adds logging [01:56] it will help me sort out the vivid issues [01:59] ericsnow: *un-reverts*? u must b having soo much fun :D [02:00] anastasiamac: imagine bamboo and fingernails [02:05] katco: are you still around? did you have anything more to say on the remaining open points on http://reviews.vapour.ws/r/1071/ ? [02:19] axw: free whenever you are [02:19] wallyworld_: omw === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54 is now known as kadams54-away [08:21] axw, ping? [08:22] mattyw: pong [09:04] morning o/ [09:09] dimitern: ping [09:12] menn0, pong [09:13] dimitern: did you see that email about issues with using MongoDB unique indexes with mgo/txn? [09:14] menn0, probably, but can you remind me the gist? [09:14] dimitern: basically you can't really use mgo/txn with a unique index [09:15] dimitern: if there's a unique index collision, the txn will appear to have worked (no error returned) [09:15] menn0, because it returns nil on violation? [09:15] dimitern: but the insert into the collection with index fails, and any other ops succeed [09:15] dimitern: so you end up with partial application [09:16] menn0, yeah, nasty [09:16] dimitern: I mention it to you because there's a bunch of networking related collections in Juju with unique indexes [09:16] dimitern: there's 2 ways around it [09:17] dimitern: 1. check for the failed insert afterwards and clean up any docs in other collections that shouldn't have been inserted [09:17] menn0, have you looked at the code that handles the nil result? [09:18] dimitern: 2. introduce another collection which has docs which have the index key as the _id and Assert on that as part of the txn (instead of using a unique index) [09:18] dimitern: the code where? [09:18] menn0, ok, these pointers are good to know, thank you [09:19] dimitern: there's a simple example linked to from the email (see the quoted bit at the bottom of Gustavo's reply) [09:19] menn0, but so far I think the only place we're using unique indexes are for networks [09:21] menn0, and they are handled correctly - check AddNetwork and AddNetworkInterface [09:21] dimitern: I hadn't checked the networking code. I just saw the indexes there and figured that this situation might not have been handled. [09:22] dimitern: looks like you guys already knew about this. [09:22] dimitern: we're probably going to go with option 2 for the case where Jesse ran into this today (not allowing multiple envs with the same name for a single owner) [09:23] dimitern: (a separate collection which tracks the uniqueness constraint) [09:23] menn0, what I wasn't quite aware of is that just the insert fails, and to watch out for partially succeeded ops in other collections [09:24] dimitern: yeah, it's pretty subtle [09:24] dimitern: i've looked at the mgo/txn code in question and see why this happens. [09:24] dimitern: mongodb doesn't return specific enough error codes for it to be able to handle this any better [09:25] menn0, even more recent versions of mongo? [09:26] dimitern: yeah. i don't think this has been fixed. basically "document already exists" and "index unique violation" are returned as the same error (and they kind of are if you think about it). but mgo/txn needs to know the difference. [09:26] brb [09:28] I see :/ [09:32] dimitern: so anyway, now you know :) [09:32] dimitern: AddNetworkInterface is fine because although it involves several collections, it only inserts into one [09:33] dimitern: AddNetowork is fine too because it only involves one collection. [09:34] menn0, ok, thanks for checking, and I'll keep that in mind for other of our cases - should we need unique indexes [09:34] dimitern: kk === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: none [10:23] dimitern: dooferlad: thx, test works now [10:24] TheMue, o/o [10:24] TheMue, \o/ even :) [10:25] dimitern: *lol* [10:28] davecheney, ping? [10:33] mattyw, hey there - have you seen my review of 994? [10:34] dimitern, I have - thank you very much, I'm mid changes at the moment, will be pinging when I'm done [10:34] mattyw, cheers [10:36] dimitern, thanks for taking a look - and thanks for the comments, all good stuff [10:36] mattyw, no worries - I'm happy to see the proposal improved considerably [10:37] dimitern, +1k [10:55] dooferlad, here's my branch - https://github.com/dimitern/juju/tree/container-addressability-fixes I've just confirmed with those changes and lxc-clone: false I successfully deployed 2 nodes with 2 containers each, and was able to do juju ssh x/lxc/y where x and y are [0,1] on EC2 [11:10] * dimitern steps out for ~1h [11:57] * TheMue -> lunch [13:30] dooferlad, ping [13:31] dimitern: hi [13:31] dooferlad, I've discovered a disturbing issue [13:31] dimitern: ? [13:32] dooferlad, both with lxc-clone: true and false and the changes in my branch I sent you earlier, I successfully live tested a scenario on EC2 [13:32] and that is bad? [13:32] dooferlad, and was able to do juju ssh 0/lxc/0 (or any other container for that matter) [13:32] morning [13:33] dooferlad, the bad part is, I left the lxc-clone: true env sitting around while I was out and now trying juju ssh 0/lxc/0 fails [13:33] dimitern: so it did work, you left it alone, it didn't [13:34] dooferlad, so something happened in the mean time - juju status shows all units are running, no issues [13:34] dimitern: so it did work, you left it alone, now it doesn't? [13:34] dooferlad, yes [13:34] dooferlad, I'm investigating === jorge_ is now known as jcastro [14:23] dooferlad, I think the issue comes from dnsmasq configured by lxc to issue dhcp addresses for containers and renew them hourly [14:25] in the 10.0.3.0/24 range [14:33] natefinch: ? [14:43] could someone spare me a review on http://reviews.vapour.ws/r/1094/ [14:44] ericsnow: it's pretty basic [14:44] talking to yourself again ericsnow ? [14:44] jw4: hey, you're not part of this conversation [14:44] hqhq [14:45] haha even [14:45] * ericsnow goes back to using his quiet voice [14:50] perrito666: sorry, gotta fix a dumb bug I introduced [14:50] np [14:51] ericsnow, presumably that PR has been reviewed a few times? Are you just looking for a graduated approver to say shipit? [14:51] jw4: noone has looked at it :( [14:51] ericsnow, it *is* a little daunting [14:51] jw4: regardless, I'll need some authority to get it landed :) [14:52] jw4: the un-revert part was already reviewed and merged last week [14:52] bamboo? fingernails? [14:52] ericsnow: I suppose it would be simpler if I split the patch in two [14:53] * ericsnow mumbles to self [14:53] jw4: ^^^ [14:53] hehehe [14:53] jw4: the torture reference was about getting the vivid stuff sorted out [14:54] oh, I thought it was related to un-reverting and assumed it was the same one [14:54] jw4: it's been a real pain because I don't have a local vivd host with which to test [14:54] Yeah, I got a utopic vm, but no vivid yet [14:55] jw4: oh, just a VM isn't sufficient :( [14:55] jw4: vivid and containers still have issues when the host isn't vivid [14:55] ericsnow, really? That's interesting [14:56] jw4: that's one word for it :P [14:56] * jw4 whispers - I do all my development in a hyper-v instance [14:57] jw4: you have all the answers, don't you? [14:57] hehe [14:58] jw4: is the performance of hyper-v good? [14:58] jw4: LXC is pretty fast and light [14:58] It seems pretty fast to me [14:59] jw4: cool [14:59] jw4: I'll have to look into that [14:59] it's hard to compare across hardware, but it handily outperforms native ubuntu on my early 2011 macbook pro with SSD and 16GB ram [15:01] the full test suite runs in about 15 minutes for me, and it's on a i7 dell optiplex from 2011 too [15:06] ericsnow: ping [15:06] wwitzel3: coming [15:27] davecheney: ping === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [15:36] Anybody interested in doing a review? http://reviews.vapour.ws/r/1096/ [15:39] TheMue, I'm on it, but keep getting distracted; should finish it soon though [15:39] mbruzek, davecheney is probably sleeping [15:40] dimitern: fine, thanks [15:40] is there something someone else on the team can help with? [15:40] dimitern: doesn't hurry, I'm on the next one. ;) [15:40] alexisb, well, dooferlad is actually OCR today [15:40] dooferlad, it wouldn't hurt to have a look as well [15:41] dimitern: on it [15:41] dooferlad, cheers! === kadams54-away is now known as kadams54 [15:52] TheMue: My non-expert opinion is that it looks fine! [15:53] dooferlad: thanks, and don't hide your light under a bushel [16:00] alexisb: I need some go help was davecheney is the person to talk with about that. I have an email out to natefinch and katco about my question. [16:01] mbruzek: yeah, sorry, meant to respond to you last night [16:01] mbruzek, dave is our resident gccgo expert [16:01] mbruzek, you can send him mail if it is not urgent, but he will be out for his weekend atm [16:02] alexisb: it is not urgent. I am sure Nate or Katherine can help [16:02] mbruzek, natefinch is currently on a critical task [16:03] mbruzek, can you forward me th email so I can help facilitate [16:03] alexisb: OK stand down natefinch, I will email davecheney and you [16:03] thanks mbruzek [16:03] mbruzek: my off the cuff response is - don't install go, just deploy a binary, but I doubt you'll like that answer :) [16:04] (but it's sort of the whole point of writing anything in Go in the first place) [16:05] natefinch: It doesn't matter if I like it or not if that is your answer. I don't know how that would survive bit rot, but yeah don't worry about it, do you critical task [16:10] Oh wow, this joyent test is totally fubared [16:11] (sorry alexisb, this is also a critical fix) [16:11] natefinch, yep I see it [16:22] who sets environment variables in table driven tests and then doesn't clear them out before the next test in the table? :/ [16:33] Evidently wallyworld_ , that's who :) [16:35] ericsnow, perrito666, TheMue, wwitzel3: can someone review this fix to a critical regression? http://reviews.vapour.ws/r/1098/diff/# [16:35] natefinch: ah, my old enemy, table-driven tests [16:35] very small fix [16:36] ericsnow: yeah.... I like them, but they're easy to abuse [16:36] natefinch: I just used them for systemd to great effect (because they were a good fit) [16:42] natefinch: done [16:42] natefinch: done [16:42] ericsnow: h5 [16:46] TheMue: :) [16:50] TheMue, you have a review [16:50] TheMue / dimitern: could you point me to where we construct the libvirt domain XML? We seem to have no network defined for kvm [16:51] dimitern: thanks and good hint, I like it [16:51] whoever told me to write a test that fails before I write a bugfix was a genius. I would have wasted so much time over my career if I didn't do that. [16:52] natefinch: :) [16:53] TheMue, np :) [16:53] that's how I found that missing defer os.SetEnv(k, ""). I wrote a test that should have failed... and it didn't. [16:53] dooferlad, we use uvt-kvm for that, which I believe creates the XML for us (or uses virsh underneath or something) [16:53] natefinch: hehe, currently doing the same with my actual fix. first a test to simulate the failure and then change to remove it again [16:53] dimitern: just found that :-) [16:54] dimitern: typical, spend 10 minutes looking, go for tea, come back, ask on IRC and it just pops up in front of me. [16:54] :D [16:57] meh non capturin groups are not something to be found in grep regexes? [17:00] you can always use grep -P [17:01] mgz: I am actually using supercat [17:01] to color my tests output so I can make more sense of them [17:02] but I try to use a non capturing group to make a match of json dicts [17:02] and it tells me that its not a valid syntax [17:02] well, generic answer then is yeah, not all regexp dialects support non-capturing groups [17:02] * perrito666 cries [17:05] perrito666: http://stackoverflow.com/questions/27242652/colorizing-golang-test-run-output [17:06] perrito666: also: http://bit.ly/1A4eY7v [17:09] natefinch: trust me youll like what I am doing [17:09] :D, it mostly colorizes the output of the logs between test failures [17:09] I donr really care for tsts when they pass [17:11] perrito666: also: https://github.com/natefinch/nolog [17:13] xwwt__: abentley: why isn't this marked as a regression? https://bugs.launchpad.net/juju-core/+bug/1424069 [17:13] Bug #1424069: juju resolve doesn't recognize error state

[17:14] alexisb: ^ [17:14] * marcoceppi is trying to figure out what constitutes a critcal bug vs a high bug [17:15] natefinch: mgz this is the kind of output I am getting http://www.webdevout.net/test?01MH [17:15] marcoceppi: I agree, it looks like a regression to me. Curtis did the triage, but unfortunately, he's out today. [17:17] abentley: cool, it's making our testing of actions in trunk a bit difficult [17:18] abentley: Looks like the inline comments issues are important, but were deprioritized to work on git. Sounds like they will be added back to the list. [17:18] marcoceppi: We don't have any functional tests of "resolve", but maybe we should. [17:18] perrito666: you could modify the code in my nolog application to change the output to include color === xwwt__ is now known as xwwt [17:18] abentley: O [17:18] abentley: I'd argue there should be, but I'm biased ;) [17:19] marcoceppi: the bug was just confused by the report/unreport/report cycle [17:19] it's still an issue in trunk fwiw [17:19] natefinch: you have a severe case of NIH [17:19] natefinch: although I might === kadams54 is now known as kadams54-away [17:20] perrito666: I have a severe case of wanting to use a real programming language to write applications [17:20] marcoceppi: We (Juju QA) only functionally test a few commands: bootstrap, deploy, upgrade-juju, add-relation, backup, restore, ensure-ha. The bulk of tests are juju-core's unit tests. [17:20] abentley: makes sense [17:21] abentley: is there liek a repo of the functional tests? [17:21] marcoceppi: All our testing stuff is in lp:juju-ci-tools [17:22] abentley: cool [17:22] natefinch: I am pretty sure supercat is written in a real programming language, I just configured it [17:24] natefinch: its in C, which beats go in what refers to "real programming language" ;) [18:09] cmars: thanks for your help [18:20] ericsnow, de nada [18:54] perrito666, the first few pages of google on 'supercat' don't seem relevant ... [18:57] jw4: yes, anything with cat on the name sucks for googling [18:57] jw4: man supercat [18:57] no man spc [18:57] ah [18:58] apt search supercat wasn't helpful either - I should have thought of the actual command name in your snippet [18:59] jw4: seems to be a rather old tool [19:00] hmm apt-get install supercat worked now cool [19:01] well it seems supercat was too much for him :p [19:57] crap, how did I manage to disable my scroll wheel in my editor? :/ [19:59] you are a talented person [20:08] * natefinch reboots... can't function w/o scroll wheel in editor. [20:19] could I get a review on a tiny patch I have up: http://reviews.vapour.ws/r/1100/ [20:20] and on an only slightly bigger one: http://reviews.vapour.ws/r/1099/ [20:25] gah, I hate it when err == nil means something is wrong... it just makes the code so hard to follow. [20:38] dammit... that feeling when you realize you waited forever for amazon to bootstrap only to realize you forgot --upload-tools [20:39] natefinch: lool [20:39] natefinch: I upload my own stream [20:39] and its all in the ctrl+r :p [20:47] I'm getting a weird error trying to deploy behind a proxy [20:48] http://paste.ubuntu.com/10552644/ [20:50] marcoceppi: I think that's the 409 error code "Conflict" no idea why you'd be getting that [20:51] http 409 error code that is [20:51] right, not idea why I'm getting it or how to get more information [20:52] try with curl? It sounds like there's a problem with the proxy [20:52] natefinch: it works on teh local system using wget [20:52] http://paste.ubuntu.com/10552661/ [20:53] ah, there we go [20:53] apparently you have to put the /right/ proxy in the configuration [20:54] when running wget from the bootstrap node, I got this "Proxy tunneling failed: ConflictUnable to establish SSL connection." [20:56] well, now it just hangs, which I guess is progress [20:57] haha [20:59] blarg [20:59] it's not respecting my proxy port [21:00] http://paste.ubuntu.com/10552707/ [21:00] how have we made it this far without hitting this in other canonical infrastructures [21:05] any suggestions :/ [21:11] marcoceppi: so your proxy is trying to redirect to a different port, too? [21:11] natefinch: it looks like Juju is trying to use port 443 [21:11] on the bootstrap node just doing a curl works [21:11] marcoceppi: it's using 443 because it's HTTPS [21:12] natefinch: but the proxy isn't running on 443, just because 443 is a common convention does not mean it's the sole port that HTTPS traffic operates on [21:12] my https_proxy line defines a port [21:16] natefinch: looking at the unit tests, for config.go, it never tests aproxy address with a port [21:16] * marcoceppi tries to patch [21:17] actually Ihave no idea what I'm doing [21:17] lol [21:18] I didn't think grep "proxy" * would return so many hits [21:19] I honestly don't know if we're supposed to support changing the port or not.... I mean, it sounds like we don't, obviously [21:19] well everything else does [21:19] I understand that, and it does seem completely reasonable [21:20] I mean, in canonical we use squid.internal:3128 for http and https, which is why I'm hitting this [21:20] but I'm not sure if that's the acutal issue or if I'm just doing something wrong [21:21] I don't see anything in the proxy code about ports, so it's likely they just weren't considered === kadams54 is now known as kadams54-away [21:22] well it's setting it properly on the host machine, just when consuming it, it seems to do something odd [21:23] I'll report a bug for now [21:23] hum, actually [21:24] that's my bad, the IP address is actually for store.juju.ubuntu.com and not the proxy address [21:24] so something else seems broken [21:25] nvm, it works now [21:25] * marcoceppi hangs head in shame [21:25] this is probably a good time to just EOW [21:26] hasha [21:26] haha [21:26] have a good weekend :) [21:28] thanks for entertaining my crazy natefinch o/ [21:28] natefinch: the releases page updated with your joyent fix: http://reports.vapour.ws/releases/2420 [21:28] natefinch: it isn't "blessed" because of unstable joyent substrate [21:28] natefinch: coincidence? === kadams54-away is now known as kadams54 [21:29] ericsnow: actually t he joyent tests are passing there, looks like [21:32] natefinch: ah, nevermind; looks like it just didn't identify the failing voting test at the top of the page === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away