[10:35] is this known? on https://uistage.jujucharms.com:8080/ , Firefox shows: SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long) [10:36] and chromium does not work either [10:52] ugh, the email overload [12:11] teknico, I don't think uistage has ever supported https [12:12] the failure behavior could definitely be nicer [12:12] gary_poster: oh, that's why. I'll correct the charm README then :-) [12:13] thanks teknico [12:16] gary_poster: we cannot yet write in the docs that we support IE, right? [12:16] correct teknico === hazmat` is now known as hazmat [12:45] jujugui is the HACKING doc up to date on the setup? Is the goal to still dev against the pyjuju ppa there? [12:47] rick_h_: I am pretty sure it is up to date in that regard. I don't think it mentions anything about how do set up juju-core and dev against that, though. [12:47] benji: yea, why I was asking as they mention needing the ppa for the websocket api and seemed that we'd be against core these days [12:48] in juju-core the websocket API (well, a slightly different one) is built-in, in that case you just need to configure the GUI to use the newer protocol [13:17] woot, desktop running tests. down to 30s hatch [13:17] but chrome update helped as well [13:17] adeuring, jcsackett, rick_h_ or sinzui: Could you please review https://code.launchpad.net/~abentley/charmworld/bulk-insert/+merge/165110 ? [13:17] abentley: i'll look [13:18] ah, the missing review finally appears [13:23] sinzui: The "Story 1" next lane is looking very empty. [13:24] we can fill it today. [13:24] guihelp: anyone available for another review of https://codereview.appspot.com/9642043 ? [13:24] sinzui: +! [13:24] +1 even. [13:24] i like +! [13:24] it shows real enthusiasm === BradCrittenden is now known as bac [13:26] abentley: r=me [13:26] adeuring: Thanks! [13:27] sinzui: Should I work on hiding oneiric? [13:27] Are you reading my screen? [13:28] sinzui: No, I did see that bug report in my email earlier. [13:29] I think we want ~charmers to make oneiric obsolete, so that ingest knows to only get data for development and supported series. We could easily just hack the code to use a blacklist of series [13:37] frankban: doing it [13:37] teknico: thanks! [13:40] benji, you saw the meeting invite for statsd, and the google doc? [13:40] gary_poster: yep [13:40] cool benji === rogpeppe1 is now known as rogpeppe [13:57] rick_h_: haha nice [14:01] CI failed [14:02] jcsackett: looks like it was your branch [14:06] "should support export" in sandbox juju api [14:06] hmm that's odd that your branch would cause that test to fail [14:07] I am thinking that we had that failure in the past as well... [14:08] frankban: still need another review? [14:08] hatch: no thanks [14:09] hatch: looking. [14:09] hatch: I need one! or rather two! :-) [14:10] teknico: the upstart branch? [14:10] hatch: yep [14:13] teknico: can you just remove PYTHONPATH without any issues anywhere else? [14:14] hatch: I'm not removing PYTHONPATH wholesale, look again :-) [14:14] ohh you're just not re-assigning it [14:14] ok nm, sorry I haven't had coffee yet :) [14:15] lgtm'd [14:15] hatch: thanks! [14:19] hatch: does that test not play well with being set as .only? i'm getting timeouts for it in trunk, pre my branch. [14:20] jcsackett: honestly I'm not sure [14:21] so if you set the suite to .only that one fails? [14:21] hatch: just that test. it.only. i'll try describe.only [14:22] hatch: ok, same for the suite. getting a fail in the before all hook. [14:22] oddly, i don't see it if i run the whole suite. [14:22] er, all tests that is. [14:22] lovely, test leakage ftw! [14:23] hatch: didn't get around to breaking up all the tests on vacation, sorry :P [14:23] haha - [14:23] jcsackett: if you want we can jump on a hangout and I can walk through debugging tips for those things [14:24] rick_h_: sure. [14:25] ccccccbljtrviklbgehhelfefnijcidliidkbjhjlluf [14:25] godammit. [14:25] glad i don't use that setting for anything. [14:26] benji, did you get a chance to verify whether statsd emitters can send aggregated initial values? [14:27] jcsackett: lol what setting? [14:27] gary_poster: I have a couple of arguments why they should not. [14:42] FYI - node 0.12 will likely be node 1.0 so we really should figure out our node issue on CI by then :) [14:47] of fun. ie stuff. [14:47] * jcsackett goes to setup ie machine [14:47] bcsaller: Hey, quick question. Can you list the different type of error states in Juju? [14:48] hatch: i'm thinking there's a good chance this isn't my branch, in which case i'm going to need to grab you or someone to analyze what's going on. i'll follow up once i can reproduce the ie failure. [14:49] jcsackett: alright thanks for looking into it, lemme know if you need me to step in [14:51] can anyone else answer my question above? [14:51] luca____: he isn't usually in for another hour [14:51] luca____: different errors apply to different objects, for example an install error is service related, but there are relation errors that can apply to relations. Juju doesn't have many 'types' of errors though. [14:51] oh hah [14:52] yeah, not really here [14:52] bcsaller: hatch hehe sorry! [14:53] bcsaller: I was trying to figure out if there was more important errors? and if you would fix a certain type before fixing the others. Also is it possible to multiple errors at the same time on the same service block? Is that plausible? [14:56] luca____: not really, hook serialization (they run one at a time in the order they happened) means you'll see one thing at a time (at a unit level). Given that we take the errors from all the units and roll them up to the service level there might be a case for what you're talking about but usually the units progress in similar phases, if one fails to install or configure there might be an issue with the charm and that impacts th [14:56] em all [14:57] bcsaller: I see, thank you [14:57] bcsaller: you can go back to sleep now :P [14:57] ha [15:03] bac: review barter? :-) [15:03] teknico: sure [15:06] gary_poster: in deploying a ghost service should we not also allow the user to configure other options than name and num units? [15:06] hatch bug 1182295 [15:06] <_mup_> Bug #1182295: adding a charm from the charm browser is broken

[15:07] * hatch bows head in shame [15:08] :-) [15:18] done teknico [15:18] bac: thanks! [15:20] luca____: the review for the issue we discussed yesterday is available if you'd like to add your comments and exercise the code: https://codereview.appspot.com/9650043 [15:20] bac: cheers, I'll write something up [15:20] ta [15:25] bac: is this better? https://codereview.appspot.com/9646043/diff/5001/config/juju-api-agent.conf.template [15:26] teknico: excellent [15:26] :-) [15:26] +1 for 'mucks' [15:26] jcsackett: how did you auth lbox to LP from the lxc container? It wants to open a browser to LP but failing to do so with a cli links and the like. [15:26] bac: that's gary's, not mine :-) [15:27] rick_h_: you might need `exec ssh-agent bash` [15:27] hatch: huh? [15:28] oh nm [15:28] I didn't read the whole thing [15:28] rick_h_: oh, it's a bad hack. :-P from outside of the lxc, `/var/lib/lxc/$lxcname/rootfs/usr/bin/lbox propose -cr` [15:28] haha nice [15:28] get through the LP validation, then kill it. [15:28] jcsackett: every time? Or just for the initial volley? [15:28] ah, ok [15:28] rick_h_: once it validates you're fine. [15:30] rick_h_: just fyi that's the command I have to run to get the ssh-agent environment variables in my ssh'd tmux terminal [15:30] without it the bzr and lbox won't auth [15:31] thanks jcsackett, onto the next issue heh [15:33] benji, rogpeppe turns out my "next call" was tomorrow, not today :-P probably not bad to have a hard limit though [15:33] benji, quick followup? [15:33] heh [15:33] guichat? [15:33] sure [15:35] jujugui: am i seeing correctly that jenkins sorted itself? [15:35] jcsackett: did you push a fix? [15:35] lol [15:35] hatch: i didn't. but other branches have landed. [15:35] ok I guess we wait [15:35] jcsackett: yea, looks like an intermittant bug found there. The test suite of doom [15:35] :) [15:35] jcsackett, :-/ and yes [15:35] that's frankban to the rescue, as usual ;-) [15:36] well, at least this forced me to finally setup an ie vm. [15:36] been avoiding that since reloading the OS. [15:37] I don't think that frankban's fix actually fixed the issue [15:37] I am pretty sure this is an intermittant bug [15:37] jcsackett: were you able to reproduce it at will? [15:38] hatch: oh, i didn't get it to happen on ie. but you can cause an error in that testsuite anytime via .only [15:38] *sigh* [15:39] that was the pyjuju api suite? [15:42] hatch, jcsackett: https://saucelabs.com/jobs/6b46469e257b453dbc09b95e565502f0# ... this one will be hard to fix, explorer sensationally crashed on the saucelabs initial page... :-/ [15:43] I don't know why but these CI failures drive me up the wall [15:47] because the tests should be solid and tell you when you've introduced regressions and having them fail willy-nilly doesn't instill confidence in your code? :) [15:48] lol [15:51] yeah that would be it [15:51] jujugui call in 9; kanbanize it, pls! [15:51] kanabanize! [15:52] yay, lbox is alive. Stupid virtualenv version issue in lxc/raring. [15:52] yay? :-) [15:52] rick_h_: when clicking a charm in the sidebar it blocks out the env while loading...could that be changed to move the loading indicator into the sidebar and then pop it open when it's ready? [15:53] (of course it COULD, wondering if there is a reason why we woudln't) :D [15:53] hatch: so we're supposed to do some animations and the like so I could see that going on. It'd be part of the overall UX polish there [15:53] alrighty cool - I've been using the browser a lot lately heh so I am coming across some oddities [15:53] hatch: plus there's changes to only have the details + sidebar be 3/4 of the screen so it'll leave some [15:54] hatch: so there's some changes/tweaks in that UX coming in the pipe I believe [15:55] jcsackett: gary_poster just a heads up, grabbing the card to feature-flag the browser by default right this minute [15:55] yay thanks rick_h_ ! [15:56] awesome [15:56] now to figure out how to actually do it lol [15:57] oh rick_h_ you can't [15:57] rick_h_, we can move feature flags earlier in stack but I don't think you need to do this for this [15:57] the flag controller needs to be moved to index first [15:58] hatch: :( [15:58] I think he will because of when the subapp is instantiated [15:58] is the flag controller processed after the other namespaces hatch? [15:58] gary_poster: well I think I'd hack the point into the main Y.App initializer [15:58] the flags are parsed after the Y.App init [15:58] if it is first then you can control it in the routes [15:59] gary_poster: well, the trouble is that all that happens in the Y.App init with the this.addSubApplications(cfg); [15:59] it seems the best thing would be to add/remove the browser subapp at that time via flag [15:59] rick_h_: best would be to move the flag code ;) [15:59] another idea but we can talk in a mo [15:59] I can tell you how to do that if you like [15:59] jujugui call now [15:59] it should be pretty trivial for you [16:00] hatch: gary_poster k, going to grab food then, after the call hit me up and we can chat. [16:00] cool [16:00] ice cold! [16:01] https://juju.ubuntu.com/community/juju-blog/ [16:03] benji: nice shirt! [16:06] bac: thanks :) [16:08] luca____: were you able to get approval on your side for the plan for URL handling? [16:09] bcsaller: do you mean this thing? https://docs.google.com/a/canonical.com/document/d/1Nn1TeSQtc5ebIwmiaotusJfI8_Vw3fRg-Dynqf2Gthg/edit [16:09] luca____: yes, thats the one [16:10] bcsaller: I haven't discussed it with Ale because she's not in a wednesdays [16:10] rick_h_, wana come by guichat? [16:10] wanna [16:10] gary_poster: sure thing, sec [16:10] ahh, ok, just trying to cross off the work-item, you'll be ping'd again ;) [16:10] thanks [16:11] bcsaller: I can't see anything that would cause an issue and I'm not sure if Ale needs to know about it hehe [16:12] I felt that way too, but some people think the URL is a notable part of UX [16:12] I didn't know if that was the case here or not [16:15] bcsaller: URL taxonomy is a part of UX but in this case it makes sense to separate browser from the canvas and allow the back button to be used for browser specific features [16:16] bcsaller: if I understood correctly you can use the back button to go back a step in the inspector, is that right? [16:18] bcsaller: hum, that's meant to say can't^ hehe fatal miss-type [16:34] luca____: yeah, I don't think it makes as much sense. If there is more than one panel open it becomes less clear. [16:36] bcsaller: yeah, it's better to relate it to one thing. Let me discuss it with Ale in the morning and we'll get back to you. Sorry for the delay! [16:36] no problem :) [16:39] some great photos http://www.theatlantic.com/infocus/2013/05/2013-national-geographic-traveler-photo-contest/100516/ [16:58] bcsaller: I suppose that if we don't need to update multiple namespaces because we won't be using them any longer then you can disregard that part of my review comment [16:59] hatch: I still don't think its clear which way we are going as even w/o updating the url state we still need to be able to parse full state to pass it along. As long as thats a goal the problem is real [16:59] so instead of dispatching gui multiple times, passing that through once and having our callbacks understand that? [17:12] hatch: I think there are a number of ways around 'how' to fix it, I'm more interested in nailing the use-case [17:13] "Support Everything!" [17:13] "Support all the things!!! [17:15] gary_poster: I'm ready to finish our discussion whenever you are. [17:18] ok I need a bzr expert [17:19] I am trying to diff my current branch from trunk [17:19] but no matter what I do it keeps giving me the trunk diff [17:19] as if I was merging it in [17:22] hatch: are you doing something like this: bzr diff -r ancestor:../trunk/ [17:22] benji: `bzr diff --old ../../trunk` [17:23] it is giving me a diff as if I was merging them, not as if I am trying to find the changes [17:23] hatch: that will work if both are up to date relative to one-another; otherwise I have been told that the form I posted is the way to go [17:23] ok lemme try that [17:24] ahh you rock [17:24] I don't even think that is documented on the diff man page [17:24] heh [17:32] hatch: it is documented in docs/process.rst [17:33] oh hah - I never would have thought to look there [17:33] I should review our docs though, see what other little tidbits I'm missing [17:39] had to turn my office fan on :/ guess it's summer now [17:39] dust.....everywhere lol [17:41] hatch: do this and never forget: bzr alias tdiff="diff -r ancestor:../trunk" [17:42] hatch: we had some 88 on monday and such. Had to kick the AC on and start hiding in the basement. I still haven't talked the wife into moving to portland yet [17:42] haha - I haven't had to kick the AC on yet, the nights are cold enough that it only gets to about 25c in here during the day :) [17:43] which is 77f [17:43] 88 would be too damn hot haha [17:43] yea, so 31C was the other day [17:43] yea, cools off for a week then back at it per forecast. <3 the basement office for this stuff [17:44] yikes that's hot [17:47] bac: not a bad idea [17:48] rick_h_: i hear there are some good brunch spots in portland. gotta get there early, though. [17:50] rick_h_: where are you now? [17:50] * hatch forgets [17:51] hatch: a bit north of detroit MI [17:51] bac: yea, it's my dream spot but that whole family and 'just built up my medical practice base' keep me chained down :P [17:53] rick_h_: just move and say they can visit :P [17:58] rick_h_: if she'd been a radiologist she could've worked remotely... [17:58] bac: hah, there you go. [17:59] how would that work? tell the patient to stand just right in the machine and then she could push the button from home? :) [17:59] "little to the left.....now hold that" [17:59] *click* [17:59] bcsaller, you available to talk through the url fragment thing in guichat? [17:59] "ok we are done, thanks" [17:59] hatch: so that's the tech, but the tech sends the images to a radiologist which is generally over the net these days [17:59] ohh I didn't know that :) [18:00] I thought the tech===radiologist [18:00] * rick_h_ used to work for a medical school that had a radiology residency and managed their T1 connections between 3 local hospitals [18:00] hatch: because radiologists are dr's that don't like people. They sit in an office and view the images on a computer and report back "yep...broken. See here [circle area with a mouse]" [18:01] then your doc tells you he noticed the break and points to the circle the radiologist made (though usually it's more detailed/technical/harder to see stuff than a bone break) [18:02] lol gotcha [18:07] so, radiologists are doctors that don't like people, in other words: if I ever decide to become a doctor, radiology is for me [18:15] lol === deryck is now known as deryck[lunch] [18:42] benji, how you liking that "Charms have to be written in Python?" thread? [18:42] you want to talk in guichat, benji? [18:43] gary_poster: heh, sure; give me one minute and I'll be there [18:43] cool [18:43] thanks [18:44] orangesquad, I have a stupid line of code mu my mongodb charm that needs rewriting. I created a temp dir using mkdtemp. That is no good since I need another user to see the contents. Do you think I can dare to create a dir with os.mkdir to set perms? [18:45] sinzui: any chance they share a group or anything? [18:46] gary_poster: did you click "join"? [18:46] rick_h_, The users are mongodb and root. and I don't think I can use the mkdtemp and set permissions [18:46] sinzui: nvm, I see that mkdtemp doesn't set a group access either [18:47] sinzui: Hmm. You could chmod after creating it. [18:47] sinzui: what file is this? maybe it'd be better to stick in swift or something? [18:47] well, maybe I need to look at the perms in the charm, I think anyone can read the tarball, so is no consequence to read the untared files [18:48] rick_h_, I unpack the tarball of the mongodb dump in a temp dir, then realised mongorestore doesn't have access. [18:49] abentley, I could do that. I think my motivation for using mkdtemp is misplaced. The hook still manually deletes the dir. [18:50] sinzui: hmm, and looks like you can't cat/tee the file into mongorestore since it wants the path itself [18:50] O K sick of writing tests....going to grab some lunch :) [18:50] ding if ya need [18:50] * rick_h_ resists urge to 'ding' hatch [18:50] * hatch had already walked away....hates rick [18:50] lol [18:51] yeah, the command is a little awkward. [18:51] sinzui: so yea, I mean why not just stick the file in /tmp, clean it up yourself, etc? What was the reason for mkdtemp? [18:52] sinzui: as you say, it has to be accessed by diff users and we don't have any 'private' data in the dump that would be revealed. [18:52] abentley, actually install_hook() is already doing that. I am just getting a random name component using tempfile. I may not need that if I have a better name rule [18:53] rick_h_, yeah. I think this is a case where I just copied code from a test to the actual function without really thinking about the consequences [18:55] "hatch" sounds like a '70s cop name. I can image him doing a lot of car chases and knocking over vegetable carts [18:55] you'll need a mustache and longer hair though [18:55] 70's pfft, that's Saskatoon today! [18:56] Oh really? Let me know when they get to the 80s. I need some think ties [18:57] s/think/thin/ [19:01] lol [19:20] HAhaha [19:20] The world needs more thin ties. [19:21] Wow, that was a while back. Kudos, me. :/ === deryck[lunch] is now known as deryck [19:44] haha sok [19:44] :) [19:46] benji, gary_poster: matthew wedgewood has submitted his first charmhelpers reorg branch, if you're interested: https://code.launchpad.net/~mew/charm-helpers/refactor-to-core/+merge/164980 [19:46] * gary_poster on call [19:46] cool [19:47] there's a lot of commented-out code in there [19:52] benji: huh, python-charmhelpers was in quantal main but removed from raring [19:52] that's odd [19:52] benji: the commented out code are things that he's moved from contrib into core, if you're looking at the same stuff i saw [19:52] yeah, that's what I figured [19:53] so it looks like he's keeping a lot of our stuff (nee python-charmhelpers) which he's moved and fixed other packages to reference [20:39] rick_h_: thought you would like to know that running the tests in chrome on my machine took 51s so 21s slower than your new desktop :) [20:53] jujugui anyone able for a review? https://codereview.appspot.com/9673044/ thanks [20:53] hatch: sure [20:53] thanks sir [21:01] bac: done [21:01] hatch: done, too [21:02] thanks! [21:04] benji, made invitation to talk more about statsd stuff early tomorrow morning. mostly a reminder for me to do it, 'cause day is busy [21:06] gary_poster: any chance you could possibly do a review on https://codereview.appspot.com/9673044/ before EOD? ppplllleeeaaassseeee [21:06] hatch, trying to run away as fast as possible. :-) looking [21:07] haha sorry :) [21:15] hatch LGTM--very nice, [21:15] running away now :-) [21:15] gary_poster: thanks, glad you like it - have a good night [21:16] :-) thx u 2 [21:26] gary_poster: sounds good