[00:08] hey rick_h_ [00:09] bac: howdy [00:09] i've gotten most things integrated and working. may need to bug you in the morning to work out why the heights aren't what i expect. [00:09] bac: sure thing [00:09] the charm panel has very tight specs for those sizings [00:09] ping me when you get in and we can run through it. [00:09] bac: k [00:10] rick_h_: it is here if you're curious lp:~bac/juju-gui/hookup-resizing-textarea [00:10] the single line inputs in the charm panel have to be 28px tall. it took some weird tweaking to get them there [00:11] bac: yea, I think that's what that single input height was for. To kind of 'check' how tall each line of text should be [00:11] bac: I'll try to look at it in the morning and see [00:12] rick_h_: i changed single_line to be either falsy or to take a height. the LP version used 1em hard coded [00:12] rick_h_: have a good night. [00:12] bac: you too [01:35] * hazmat watches gary_poster fill up the inbox in real time [01:35] :-) [01:36] thanks [01:36] welcome (glad it is a good thing; was a bit worried about subscribing juju-gui but thought it was appropriate) [01:38] oh, is that why I'm getting dupes? [01:38] ok, thought I had done it wrong when I sub'd to everything [01:50] sorry rick_h_ [01:50] gary_poster: no, all good. Was curious checking if they were new ones I missed/etc [01:50] :-) [01:50] I added three [01:51] added juju-gui for those [01:51] cool [09:31] morning rogpeppe [09:32] frankban: hiya [09:32] bug 1160971 seems fixed, I attached the script used to dupe it, now it works well, do you want me to mark it as fix release in juju-core? [09:32] <_mup_> Bug #1160971: WebSocket disconnects when an invalid request is sent

[09:33] frankban: cool. i thought it probably was but your pastebin has disappeared so wanted to check with you [09:33] frankban: it's incredibly annoying that pastebin has lost everything [09:33] rogpeppe: yes, it's not a reliable tool for this kind of things [09:34] frankban: tbh i think they have a responsibility to keep all the pastes around [09:34] frankban: they're a specific kind of history and really quite important [09:36] rogpeppe: I agree, IIRC there was some discussion in some ml about this issue. [09:37] rogpeppe: anyway, marking it as "fix released" if you agree. [09:37] frankban: in particular a lot of IRC discussion logs will be less useful without the pastes [09:37] frankban: sgtm [09:39] rogpeppe: cool. oh, and congrats for your spotlight award, you deserved it! :-) [09:39] frankban: thanks! [09:39] frankban: you guys have been awesome too [09:40] :-) [11:42] anyone know what the config is on the charm to not have it ask for the password? I'm not seeing a config option for that. [11:46] rick_h_: as far as I can tell if you deploy to py-juju and set "staging" to true in the config, then it shouldn't request a password [11:47] benji: cool, /me goes to try [11:48] cool though, first time I've deployed juju-gui and into an environment with our charmworld stuff [11:49] sweet https://ec2-54-224-200-253.compute-1.amazonaws.com/bws/fullscreen [11:50] gary_poster: so this is a juju-gui using svg image links back to charmworld serving the svg image files working. [11:50] gary_poster: still no gzip, but I think it works out well [11:52] thanks benji, worked [11:52] cool [11:52] <3 using uistage to look up charm config options and descriptions lol [11:52] dogfooding! [11:52] :) [12:09] rick_h_, yeah, way better! [12:10] gary_poster: I think so. I'll bring it up in our stand up for review from others and then we'll see about breaking the work down into backend/front end cards [12:10] cool [12:11] and this has the charmworld server doing the correct trimmed OPTION request, so 231B pre-flight with 158K of data [12:11] so much better than over 1M [12:12] cool, rick_h_. If you cache for switch between full and sidepanel then I think that will be a pretty good resolution [12:12] I mean, the combined package [12:12] gary_poster: right [12:14] rick_h_, so is that instance trunk, or a custom branch of yours? I could update the sandbox version and then we could have this behavior on the demo if you want--and the sandbox will make it feel asnappier also [12:15] gary_poster: it's a custom branch of charmworld and juju-gui that just implemented a quick hack to proof it out [12:16] rick_h_, ok cool [12:16] gary_poster: so we have to go back and add the feature to charmworld, with tests, etc. and the front end [12:16] I actually really like this 'create a branch, hack feature in, launch charms, point at hack branches...test' [12:17] really kind of cool to A/B ish feature test [12:17] add feature and tests: yeah, understood rick_h_ . Is that a "by the end of this week" thing, if it were prioritized, do you think rick_h_ (understanding that it might not be prioritized and your estimate might be wrong and la la la la) ;-) [12:18] rick_h_, cool to test with: agree. lightweight deployment is very nice. makes me want it even more lighter weight :-) particularly for iterative development and testing [12:18] gary_poster: I'll ask in the stand up. I think since it can make the demo better it will be my/abentley's goal for today, but not sure [12:18] cool [12:19] gary_poster: I do need a hand from someone in debugging an issue I've got that only shows in prod mode. however, when I try to run make prod I get 404's vs the app [12:19] huh [12:19] gary_poster: just at some point today if someone is experienced in how prodmode is setup/diff [12:19] rick_h_, yeah I know that. now's about as good time as I'll get. If we can't figure it out quickly I can hand it off [12:19] https://bugs.launchpad.net/juju-gui/+bug/1175183 only happens in production mode, but running that locally would 404 when I go to 127.../bws/fullscreen and such [12:19] <_mup_> Bug #1175183: Filters checkboxes should not act as radio buttons

[12:19] I mean, I know about that [12:20] ah [12:20] yeah [12:21] prod mode is simply dumber atm, in that the backing webserver can't serve index.html from arbitrary urls [12:21] so quick hack: [12:21] merge your "charmbrowser defaul" branch and debug [12:21] ah, gotcha. makes sense. [12:21] alternative, maybe quick hack: [12:21] thanks, will do [12:22] look at devel and try to switch that to serve prod temporarily [12:22] cool [12:36] benji, if you want to talk about memory, I have about 10 or 15 [12:36] gary_poster: sounds good. the regular place? [12:36] sure benji [12:39] hi rick_h_, thanks for your email and explanation [12:40] rick_h_: upon further investigation i did see that the fields on the charm panel have a line-height and height of 18px, so it is working just fine [12:40] bac: np, thinking it's the generic css rules from input -> textarea getting in the way if I'm lokoing at the right spot [12:40] rick_h_: and those are the ones we're trying to match [12:40] bac: yep, that's what I was going to add today. I missed putting line-height in those css notes [12:40] so font-size, line-height, padding, border all come into the combined height you end up getting [12:41] rick_h_: there is a problem with the service settings page, though. if you still have my branch could you add haproxy and then look at http://localhost:8888/:gui:/service/haproxy/config/ when you have time? [12:41] bac: I can pull it back down. give me a few. [12:48] bac: ok, loaded and on that url [12:48] so if you look down at service, one of the last ones [12:49] k [12:49] bac: ok, so this should be opened up? [12:49] rick_h_: you'll see it is a single line, though it is populated with multi-line data. a keypress in there will cause it to expand [12:49] righto [12:49] k, /me goes and looks at code/etc for a bit [12:50] i'm stepping through the resize() method called at the end of the initializer now. that is where it is supposed to get expanded [12:51] bac: right, but in resize it checks for single_line and trumps the height in that first if condition I'd expect [12:51] rick_h_: ah, i think maybe _prev_scroll_height should not be initialized to 0 [12:52] rick_h_: i see this behavior whether using single_line or now [12:52] not [12:52] bac: so this was built to work with the inline editor such as the bug title, so that a single line would expand only when you were editing [12:52] rick_h_: funny thing is it works in charm panel when using single_line [12:52] in this view it does not work either way [12:52] bac: k, looking [12:57] ugh, multi dispatch FML. Goes through this debug code so many times [12:58] bac, what view is doing the initial work here? loading plugging the textareas? [12:58] bac: actually, want to chat for a second? [12:59] sure [12:59] bac: looks like the normal hangout is taken, sec [12:59] k [13:00] bac: https://plus.google.com/hangouts/_/439096b6bd109b21f6137274b06438e42739fdb0?authuser=0&hl=en [13:38] rick_h_, I think I LGTM'd everything from Huw [13:38] thanks gary_poster [13:39] welcome [13:44] hi gary_poster -- the integration with the resizing textarea is going well. it works in the charm panel but is not happy in the service settings view. rick and i know what's going on and i'm chasing it down. [13:44] awesome bac! [13:44] thanks for heads up [13:55] bac: after I cleared my browser 100x I did get it to hit those debuggers but the Y.Array.each wasn't seeming to get hit. [13:55] rick_h_: similar here [14:02] bac: bah, you don't need to Y.Array.each a nodelist, you should be able to just do view.tareas.each(... [14:02] rick_h_: i'm confused. when the break point hits, view.tareas is an array with 12 elements. the breakpoint inside the .each never hits, though [14:02] bac: if you get a sec try that. If not I'll give it a go after I get this stuff landed for huw [14:06] rick_h_: that works if you do tarea.resizingTextarea.resize(); -- the plugin must be included [14:06] bac: ah! awesome [14:07] bac: so at least a hack can make it work then. Might check with hatch or someone more up on showView() to see if there's a better place to hook into. A 'rendered' event or something. Otherwise, this gets around the issue at least [14:07] whaaaadauuupppp [14:08] hey hatch [14:08] beetlejuice ... beetlejuice ... [14:08] BEETLEJUICE!!!!!! [14:09] so in services.js views.service_config there is a container that i'm using to add the resizing textarea plugin [14:10] hatch: all well and good, but that container has not yet been added to the DOM, so the initial size computations are all zero [14:11] hatch: I couldn't figure out how/when showView() from _buildServiceView() actually put the thing in the DOM [14:12] hatch: in app.js, so we put some hack code into the callback for post-showView() but feels hacky [14:12] hatch: http://paste.ubuntu.com/5625996/ [14:13] * hatch creates a card for everyone to use gist.github.com so we can have editing and syntax highlighting [14:13] ;) [14:13] hatch: replies! [14:14] paste.mitechie.com :) lodgeit ftw [14:14] sorry I had to run and take the garbage out....not that it mattered I missed the damn truck [14:14] gists are mini git repos, nothing beats that :) [14:15] bac: rick_h_ so that's how you're supposed to do it - th eonly change I would do is have a method you call in the view to do that each() [14:15] hatch: yea, makes sense. view.fixTextAreas() [14:15] haha - well....instantitateTextAreas :P [14:16] view.inTheDippyDomNow() [14:16] :P [14:16] view.lickyBoomBoomDown [14:16] view.informer [14:17] view.blam [14:17] name that song! first person wins 1 internet [14:20] no, not Snow, anyone but Snow [14:20] lol [14:21] that just makes me want to start 'ice ice baby'ing around the house [14:21] rick_h_, hatch: yeah perhaps we should not attach the plugin until after showview [14:21] I'll take two Vanilla Ices (Icies?) over Snow [14:21] bac: or that. [14:21] http://www.youtube.com/watch?v=NtILxBszyf8 [14:21] Especially now that he is a general contractor with a renovation TV show [14:21] I want those sunglasses [14:21] lol [14:22] benji: haha really? [14:22] yep [14:22] who saw that career change coming? [14:23] hatch: https://www.youtube.com/watch?v=IrNiiNRCvYo [14:23] vanilla ice !== snow :) [14:24] oh [14:24] sorry too early [14:24] missed the convo changing tracks [14:24] :) [14:28] jujugui - has anyone looked into these CI failures? I think this one is fixable [14:29] hatch, I tried yesterday. sent email. [14:29] 2013-05-02 14:27:27,704 DEBUG openstack: 400 '{"badRequest": {"message": "Can not find requested image", "code": 400}}' [14:29] oh woops sorry I'm 100+ behind in my emails [14:29] hatch, we must fix it. make distfile might be broken? [14:30] possible, I'll grab my laptop and log into it [14:30] see what I can do to fix it [14:32] hatch make distfile works on trunk. this is on charm apparently. do you know where to find the right image numbers offhand? [14:32] if you can fix CI, teknico is looking at broken charm [14:32] isn't that euca-describe-images or something [14:32] was just looking it up [14:32] hatch something like that but then you have to know which one to choose of a zillion [14:33] I'll pick the one with the coolest name [14:33] heh [14:33] honestly I was going to see what the old one was and try and find something similar [14:35] gary_poster, hatch, teknico: it seems that make distfile is broken in trunk: http://pastebin.ubuntu.com/5626062/ [14:35] oh ok [14:35] frankban, worked for me after make clean. maybe make clean-all is necessary to trigger [14:36] gary_poster: oh, trying [14:38] ok well if you guys are on it i'll get back to gui stuff [14:38] gary_poster: still an error [14:38] hatch, multiple problems [14:38] hatch if you can fix image name that would be fanulous [14:38] fabulous even [14:38] (make clean-all && make distfile) [14:39] ohh ok [14:39] frankban, weird. I got a fresh branch and WFM. Raring, yeah? [14:39] gary_poster: FYI manage.j.c is updated with fixes to the OPTIONS request and gzip is now enabled so tinyurl.com/jujucharms should hurt less. [14:39] gary_poster: yes, trying on a branch [14:39] frankban, and the failure was the same as before ? " bin/py: File removed before we read it" is weird error [14:40] gary_poster: yes [14:40] rick_h_, awesome thanks. once fires are out I'll also update tinyurl.com/jujucharms [14:46] hmm I cannot remember how we specify the image to use [14:46] hatch in ~/.juju/environments.yaml [14:47] ohh right right [14:50] umm....image id's are in the format aXi-XXXXXXXX - the one in the env.yaml looks like a hash of some type [14:51] or am I missing something here? [14:51] gary_poster: it was a local problem: bin/py broken symbolic link in my trunk branch, not removed by make clean-all [14:51] frankban, ah ok cool. [14:52] so as far as images go - do we want 64bit raring? [14:52] hatch no [14:52] we want 64 bit precise [14:52] or stay with 12.04? [14:54] does anyone have any idea how that id got changed? [14:54] hatch 12.04 [14:55] hatch the id changed probably because they have improvements to the image [14:55] newer sources [14:55] that sort of thing [14:55] no I mean they aren't even in the same format [14:55] the one in our env.yaml is a huge hash [14:55] not the format of the image id's [14:56] hmph who knows I'll keep it just in case [14:57] hatch, sorry, trying to get over at the machine to look. have a call in 3 [14:57] and was just off another call [14:57] sure np - I am just looking through the list of images [14:57] I think we want ubuntu-released image? [14:57] sounds like it would make the most sense :) [14:58] yes hatch I think so. Although if it has "smoser" in the name it is fine too I think [14:58] there are those too but they are further down - I'll try this one for now [14:58] ok [15:00] ok id updated and new build kicked off [15:00] really wondering how that id got changed [15:05] hmm now it's saying invalid image ref provided [15:05] hatch http://10.189.74.2:8080/job/jujugui-test-charm/385/console [15:05] I'm confused... [15:05] not good image [15:06] ok will try the smore one [15:07] here are some charm changes, I'd like a few eyes on it, possibly frankban's, and bcsaller_'s when he's around: https://codereview.appspot.com/9121043/ [15:07] I even did a pre-review of sorts to help you out :-) [15:07] kicked off build again [15:08] teknico: will do [15:08] frankban, thanks [15:09] ok invalid image ref again...it must not like the id format [15:09] so I need to somehow associate the id in the euca list to some hash? [15:10] according to the canonistack documentation it's the proper ID format [15:11] checking in #canonical-support [15:12] orr..... matsubara you around? [15:12] hatch, yep [15:13] so we started getting these errors last week [15:13] DEBUG openstack: 400 '{"badRequest": {"message": "Can not find requested image", "code": 400}}' [15:13] and when I view the environments.yaml file the ID is a large hash [15:13] but when I change it to a proper ID it gives me an invalid ref id [15:13] ERROR Unexpected 400: '{"badRequest": {"message": "Invalid imageRef provided.", "code": 400}}' [15:13] hatch, deploying on canonistack? [15:13] yeah [15:14] so it's like it's expecting a large hash ID not the one that's in euca-describe-images [15:18] hatch, can you deploy locally from your laptop? [15:19] I can try [15:19] but I'm going to guess no [15:19] heh [15:21] that also has the large hash i'd [15:21] ids [15:21] I can't remember where those came from [15:21] but no - can't find the requested image [15:21] hatch, sorry, got disconnected. I think smoser knows the id to use. maybe ask on #is? [15:22] ok so it doesn't follow the canonistack documentation on wiki any more? [15:22] the id's from euca-describe-images aren't valid? [15:23] ok I asked him [15:24] hatch, this is in the env.yaml file for the charmworld project: default-image-id: bb636e4f-79d7-4d6b-b13b-c7d53419fd5a [15:25] yeah same we have [15:25] which doesn't work [15:25] hey hazmat. https://blueprints.launchpad.net/juju-gui/+spec/servercloud-s-juju-gui-read-only-for-is is the blueprint. It is for juju-gui. I think you need a juju-core blueprint. That will be one that GUI follows [15:25] I think I should try to delet the gui one [15:25] e [15:25] gary_poster, ack, thanks [15:28] hatch, might be a problem on canonistack itself [15:28] just got an id - and an explanation as to what's up [15:28] so /me happy [15:28] cool [15:28] noooooooooo bug in yui makes me sad...well at least lack of support [15:29] which bug? [15:29] hazmat, I was wrong: https://blueprints.launchpad.net/juju-core/+spec/servercloud-s-juju-core-role-based-access-control [15:30] have at it :-) [15:30] gary_poster: jenkins is about to shut down so when it's back we'll see if this new ID works...and I also found out why there is a discrepecy and will update the documentation [15:30] hatch: working on it. Looks like it has two query string parsers. One in http://yuilibrary.com/yui/docs/api/files/app_js_router.js.html#l994 [15:30] hatch: and the query string module itself [15:30] hatch, and can you also document what to do in the future when this happens? :-) [15:30] rick_h_: keep in mind we have totally bastardized that router code :) [15:30] hatch: the one in the router code is dumb and can't handle querystring: "category=databases&category=file_servers& [15:30] gary_poster: definitely - I was getting frustrated hah [15:30] where a key is in there twice to turn into an [] [15:30] :-) cool [15:43] rick_h_: that's because query strings with multiple of the same keys are technically invalid :) [15:44] hatch: but but but [15:44] hatch: it works in dev mode :P [15:44] haha no I agree it's a commonly used feature [15:45] hatch: only fails in production so building tests against Y.QueryString and Y.Route atm [15:45] oh really? that's interesting [15:46] hatch: http://jsbin.com/efofol/1/ [15:47] hatch: so for some reason in dev it's using Y.QueryString but in production using Y.Router._parseQuery and thus breaking my filters [15:47] hatch: anyway, will ahve to find some way to cheat it when I get back from lunch. bbl [15:48] ohhhhh [15:48] now I see what's going on [15:50] juju kanban now please [15:50] jujugui I mean [15:51] bcsaller, any idea when your branch might land? if soon I will wait to update tinyurl.com/jujucharms [15:53] gary_poster: I pushed a number of updates a minute ago, I think I if I could get a second review on https://codereview.appspot.com/9070043/ I'm ok with it as an intermediate step [15:54] bcsaller_, cool, let's rustle someone up on the call [15:54] redoing the propose now [15:55] gary_poster: did you ever get it to work in practice? [15:55] bcsaller_, aigh! no! doing now. [15:58] bcsaller, lol that's *awesome* [15:58] heh :) [15:58] bcsaller_, I will have to do a live demo on call :-P [15:59] bcsaller_, qa: cannot add or remove relations to imported bits [16:00] maybe fixed [16:00] but just pulled [16:00] oops [16:00] jujugui call nowq [16:00] gary_poster: yeah, should work now [16:05] jovan2: i'd like you to look at the expanding textareas. i have an instance coming up at http://ec2-50-19-207-147.compute-1.amazonaws.com and it will be available soon [16:05] https://codereview.appspot.com/9070043/ [16:06] bac: sure [16:12] bac: pwd? [16:12] Makyo: congrats! [16:12] Thanks :) [16:15] I found out this morning we made a couple of the local papers, too, since it was the first day. :P [16:16] jovan2: trying to get it [16:18] bcsaller_, frankban, thanks for the reviews! [16:23] LF review for doc update https://codereview.appspot.com/9124043/ [16:24] hatch, maybe mention how to choose the ids? look for precise, and...? [16:24] now that the CI is back up we have failures in IE [16:24] :-( [16:24] gary_poster: adding [16:24] thanks [16:27] gary_poster: proposing [16:28] hey rick_h_, could you look at the above ec2 url? [16:29] updated [16:31] * bac lunches [16:33] gary_poster: "the Juju API cannot accept a websocket directly (it expects to have to upgrade it)" [16:33] gary_poster: what does that mean? [16:34] rogpeppe, it may be no longer relevant, Where is that? on call [16:34] gary_poster: it's from servercloud-s-juju-core-role-based-access-control [16:37] rogpeppe, could you delete? not relevant [16:39] gary_poster: ah actually - i'd missed the fact that that comment was talking specifically about py juju [16:39] gary_poster: so probably still relevant [16:39] yes === matsubara is now known as matsubara-lunch [16:48] bac: did you test your textarea stuff in IE? it looks like it's breaking the CI [16:48] sorry... :) [16:57] hatch, It hasn't landed yet, has it? [16:58] the video shows a 'textarea' suite failing [16:58] Was it landed as separate branches, then? [16:58] I can't seem to stop the video to see what the title actually says [16:58] I have no idea [17:16] hatch, some of it landed a while ago [17:16] specifically some standalone plugin tests [17:16] IIRC [17:17] the new branch actually integrates it [17:17] ohh ok - looks like it's those tests which are failing in IE [17:18] bac, LGTM with comments plus fixing the IE tests from previous checkin [17:21] benji did you run the charm tests when you landed? teknico reported that tests were broken in trunk [17:23] frankban, LGTM. Did deploy tests also fail for you? [17:24] gary_poster: not tried, teknico said they were failing in trunk, I suggested to handle that in another card. I can check it tomorrow [17:24] ok thanks frankban. have a good evening [17:24] gary_poster: you too! [17:30] bcsaller_, I still cannot add or remove relations on imported services with tip of your branch [17:31] gary_poster: yeah, I loaded the charms so I thought it would work, I'm looking at that now, very odd error [17:31] this.db.charms.get('id') [17:31] ["cs:precise/memcached-6", "cs:precise/wordpress-14", "cs:precise/mysql-19", "cs:precise/mediawiki-8", "cs:precise/haproxy-17"] [17:31] app.db.charms.get('id') [17:31] ["cs:precise/memcached-6", "cs:precise/wordpress-10", "cs:precise/mysql-16", "cs:precise/mediawiki-6", "cs:precise/haproxy-16"] [17:31] where 'this' is the fakebackend [17:31] that's a lot of smiley faces [17:32] hatch: you have a very expressive IRC client [17:32] yeah it even does inline pastebins, images, and autoresolves tinyurls [17:34] bcsaller_, weird...so fakebackend is not honoring the service revision [17:34] bcsaller_, maybe it can't honor it? [17:35] gary_poster: or they are pulling from the old and the new sources [17:35] bcsaller_, because the charm store only offers current versions? and so the solution is to reconcile? [17:35] on the service [17:36] bcsaller_, I think that is it: line 325 of fakebackend [17:36] this.get('charmStore').loadByPath( [17:36] charmIdParts.charm_store_path [17:37] if you go get that json... [17:37] I suspect you're correct [17:40] bcsaller_, yup: http://jujucharms.com/charms/precise/wordpress-10/json (look for store_revision and compare with url) [17:40] or store_url for that matter [17:41] the the imports are not going be the current version much of the time anyway [17:41]