[00:01] rick_h: NP, hard work all round. Nice to finally have it released! [00:29] morning [00:30] I haven't had anyone rage tweet me yet about a bug so it must be working well ;) [00:31] hatch: I broke something, but I can't reproduce it [00:31] well then that's someone elses problem isn't it? :P [00:31] hatch: And someone said they went to "view all notifications" and there's no way out [00:31] out/back [00:32] hmm there is DEFINITELY a bug there....but the backbutton and hitting the juju link both work to get out [00:36] Ah right [00:47] I saw a 'It takes too long to load' tweet, but that's bout it. [00:48] yeah - that was probably part of the 250http requests it was making lol [00:49] It's a request per image in any photo site, we just delay all that :) [00:51] no the js wasn't being rolled up [00:51] :) [00:52] latest blog post http://fromanegg.com/post/56193994218/juju-gui-v0-8-and-jujucharms-com-released [00:52] Ohhh [00:52] Rock on. [00:52] I did tweets, and I redid the screencast today with my mic. [00:53] oh awesome! [00:53] where is the link to the vid I'll add it to the post [00:53] I lost everything in a few catastrophic crashes, so the end result is still rougher than I'd like, but hey, marketing materials. [00:54] aww boo! [00:54] It will be at https://www.youtube.com/watch?v=W3RDt3YpikM Still processing. [00:54] Just a few verbal stumbles, no sound problems. [00:54] ahh well those happen [00:55] thanks I'll be sure to embed as soon as it's up [00:55] does it give you an eta? I've never uploaded a video before [00:55] Only on uploads, not on processing. [00:56] Can preview here, I guess: http://ubuntuone.com/5EjNP5D50mRe2PxXa9yhl6 But that's the full HD video. [00:56] couple of oddities on jujucharms.com [00:56] no thanks [00:56] :) [00:56] hey hazmat, what did you run into? [00:57] hatch, jujucharms.com, search for log, click logstash-agent, click interface get a redirect, looks like some oddity around the icon fetching [00:58] hatch, doing a full reload on the logstash-agent page and the interface 'tab' loads fine [00:58] yeah then the browser appears to think it's in the logstash charm [00:59] hazmat: ok I see what the issue is....I think [00:59] trying to repro [01:01] yeah it looks like there is a error which is causing the click handler to not 'prevent default' [01:01] i can get some other ones where the main content well grays out [01:01] but navigation works [01:01] yeah this is an odd one [01:02] at least it's repro-able so we should be able to track it down [01:02] can I impose on you to file a bug? :) [01:03] sure [01:03] thanks :) [01:18] hazmat in chrome? [01:18] there's a known routing bug that changes the url and causes a redispatch in chrome [01:25] rick_h, in chrome [01:26] er. chromium [02:00] hatch, gave you the wrong URL: http://www.youtube.com/watch?v=V2H3fat0K5w [02:07] hatch: yea, wild day today :) [02:23] Makyo: much better sounding [02:24] Makyo: remind me next sprint. I've got a 2 port USB audio box and a trio of condenser mics and pop filters for when we did interviews at OLF and PyCon [02:24] rick_h, Yeah, the difference between the mic under the keyboard and anything external is impressive :P [02:25] rick_h, Oh? Rock on :D My mic's a bit big to bring traveling, but I do have a portable Tascam. The mics might be better, since it's not a separate device, don't have to fool around with kdenlive to sync things. [02:25] actually have an 8-port M-Audio but only works under windows/mac so it's only ran once :( [02:25] Makyo: yea, I got a series of stuff for doing traveling interviews. Table top mic stands, etc [02:25] Awesome :D [02:26] heh, I could watch this all day :) [02:27] check out how fast that search is :P [02:29] lol, nice closing Makyo [02:29] 'adds a bit of charm on the top" [02:30] Hah, yeah, figured something cute to close it out :) [03:36] Makyo: yes...yes you did [03:36] :) [03:36] ? [03:36] re url [03:36] YT created two links, one is still dead :/ At least we still have the other! [03:38] post updated with video [03:38] you're gona be famous [03:38] eFamous. [03:38] iFamous [03:39] infamous [03:40] crazy Ubuntu Edge is over $3m === rogpeppe1 is now known as rogpeppe [12:17] jujugui reviews please for a hot item of getting the charm details left breakout panel working to show off (though lots of bugs in it still) https://codereview.appspot.com/11714043 [12:17] rick_h: o/ [12:17] rick_h, cool! on it [12:17] is gary_pos` your rap name? [12:17] lol [12:17] hah! === gary_pos` is now known as gary_poster [12:18] rick_h: I'll do the second review [12:19] benji: i'm already doing it [12:19] I was going to do second review buit now I'll just do extra qa :-) [12:19] didn't you see me raise my hand? [12:19] bac: oh, I missed that; next time wave harder [12:19] benji and bac are doing the reviews! /me said happily [12:19] i like that plan [12:19] o////// [12:19] heh [12:19] lol [12:19] thanks guys, appreciate it. Just realize that things like the events and such in the working charm details are borked a bit. The tabs updates the url, and some links want to work a bit strangely. but it displays and loads content in a readable way [12:20] rick_h: so hold off on reviewing? [12:20] stand down [12:20] benji: no, this is a step [12:20] please review [12:20] k [12:20] stand up! [12:20] will follow up with more clean up and such. But this reorg of the html/css needs to go forward [12:21] I'm just trying to prevent a bunch of bugs getting filed after this :) [12:21] and with that...time to make some coffee [12:35] so sil wrote an indicator widget to track ubuntu edge and gustavo (i assume) put this graph together http://ubuntu-edge.info . [12:36] yea, with data ...let there be visualizations [13:12] benji: replying and updated branch coming. I didn't update all the CSS because honestly I indented it one left under .juju-inspector and would rather not refactor it in this branch atm. [13:12] benji: and I didn't get the reference... I fail :( [13:12] benji: QA go ok? or bac were you going to come back for QA? [13:13] rick_h: that's completely understandable (the non-changes to CSS and the reference non-getting) [13:13] rick_h: oh, I didn't QA; but I can. Shall I? [13:13] benji: appreciated. I'm going to try to run it through some more browsers to be sure but QA is appreciated [13:14] I'll QA now. [13:14] rick_h: actually i didn't qa as i thought gary_poster was going to. i will now. [13:16] hmm, so yea I see in FF the inspector doesn't remove on close but it does on chrome...wtf [13:17] and wow FF is slow to start up [13:24] rick_h, bac, sorry, did basic qa on cherome and looked good. didn't get farther because of calls [13:24] chrome [13:25] rick_h, nice (maybe?) quick fix would be fixing height the way we do for the inspector itself. I think we do it wrong for ghost though [13:25] FF is being very inconsistent with me. Maybe I should load a non-nightly version. [13:26] rick_h: so that breakout panel has no scrolling. i assume that is known. [13:27] bac: yea, just looking at that with gary here. I think I need to change that from the viewlet container to the overall container perhaps. Testing now [13:27] cool. i'd never seen it before. will be nice. [13:27] rick_h: thanks, btw, for the nice QA instructions. i think we should strive to make that part of all MPs [13:28] bac: hmm, though it would require the tab changes to re-run the calculate height on the viewlet manager somehow. [13:29] IANAUXD but the white panel with no border looks naked to me [13:32] rick_h: QA-wise I can't see any problems [13:33] thanks, looking to see if I can get scrolling before landing. [14:01] morning [14:03] sinzui: I note that charmworld/6, apache2/3 and mongodb/0 all have agents down. Reboot them? [14:04] Shall I reboot them? [14:04] abentley, yes please :( [14:04] abentley, I rebooted charmworld and mongodb yesterday or the day before to [14:04] too [14:05] abentley, oh, and I rebooted the basenode last week [14:05] somethings is very sad in canonistack [14:10] sinzui: Everything is back up. [14:11] :) [14:17] gary_poster: is there something particular you would like me on right now? [14:18] gary_poster: landing the charm details branch right now. I got the scrolling working in it. So it should be 'good enough' for 'oooh pretty' demo purposes if you want to work with the guys out at OSCON on that. [14:18] hatch, gimme one sec [14:18] sure np [14:18] rick_h, awesome, thanks! [14:18] gary_poster: the next plan is to finish up the CSS and get autocomplete landed and then will head back to bugs/making the charm details less 'there be dragons' [14:19] Will be in a little late, have to take the dogs to dog camp today, had forgotten. Back in a little bit. [14:19] Makyo: so yay that sprint work closes up a bit. [14:19] Makyo: we call it 'puppy school' :) [14:20] rick_h, sound perfect! thanks [14:20] Woo! Will push to get local charms figured out today, then. [14:21] Makyo: yea, let me know if we need to chat on how we can work that out. [14:21] it's one of the big 'dragons' but figure they won't hit that in a demo [14:25] ok hatch, one silly task but great for oscon would be to make unit collections ordered, and initially closed [14:25] gary_poster: can do! [14:26] decending order by the machine number? [14:26] the headings are already ordered [14:26] hatch thanks. no, I mean headings. oh, yeah, lemme see [14:28] hatch headings don't seem to be ordered to me [14:28] hatch I go to http://comingsoon.jujucharms.com/:flags:/serviceInspector/ [14:28] deploy 100 of mysql [14:28] checking [14:28] type cntrl-s to turn o nsimulator [14:28] abentley, I am very tempted to create a view that return a charmworld heartbeat right now. If I land that, I can remove the "latest" routes you want me to move [14:28] and I see running before errors, for instance [14:28] too many things to do right now [14:29] sinzui: That would be great. [14:29] gary_poster: hmm that's a regression [14:29] I'll look into it [14:30] thanks hatch. next task maybe: we are getting reports of people (including our CEO) going to jujucharms.com and getting "connecting to juju environment" forever [14:30] hatch I can't dupe [14:30] that happens when there is a console error [14:30] hatch, possible approaches would be [14:31] I wonder if we can trap those somehow... [14:31] hatch that's what I thought [14:31] hatch, we could trap and then ask user to report? [14:31] via email or something lame? [14:32] capturing info for us? Or we could send to google analyticsw? [14:32] yeah until we have something 'proper' set up [14:32] we have the events now [14:32] in GA [14:32] I'm not sure we can send that much data into analytics [14:32] so we could send arbitrary things [14:32] I could be wrong though [14:32] bac, was there a limit as to how much we could stasgh in the GA events? [14:33] sinzui, in a similar "respond to events before they are emergencies" approach, it would be nice to do some kind of stress testing of m.j.c sometime very soon to see if we can stomp out the 504s. [14:34] gary_poster: i don't recall [14:34] bac, cool np [14:34] hatch, anyway, offer to email and maybe offer to reload? very open to suggestions :-) [14:35] yeah I'm just not sure how to capture the error [14:35] well...in a way that makes sense [14:35] can't wrap the whole app in a try/catch :P [14:35] and it's a bit of work to write our own exception handler [14:35] hatch why not? can't we do a try catch on index.html? [14:35] around Y.use? [14:36] I 'think' YUI captures some of these errors automatically [14:36] hatch, another approach would be to have a setTimeout loop that keeps track of progress [14:37] if we've been waiting too long then we start ofering help [14:37] gary_poster: the 504s were brought up in the config change where a timeout was moved from 1s to 3s before responding with a 504. [14:38] hazmat: I've replied to your comments on https://code.launchpad.net/~abentley/juju-deployer/get-flattened-deployment/+merge/175689 do any of my proposals suit you? Or what would you like done? [14:38] gary_poster: that could work as a first step - but of course we would like something somehwat automated so we can get the real errors [14:38] rick_h, ack. but does that tell us anything about root cause or remediation? IIUC that's a band-aid not a solution [14:39] abentley, i guess i'm trying to understand better the goal, you don't have any files in this context? you just have the full data structure to do resolve parents on ? [14:39] abentley, is the context charmworld ingest of a bundle? [14:39] hazmat: Right, and right. [14:40] looks like google is indexing mange.jujucharms.com again [14:40] abentley, also the underlying branch for the mp has changed significantly [14:40] gary_poster: first I'd probably like to try wrapping our instantiation of app in a try/catch and see if errors bubble up [14:40] or if they are caught lower [14:40] the mp target that is [14:40] hazmat: I saw. [14:41] jcsackett, hangout? [14:41] sinzui: already there. [14:48] hatch +1. I think they bubble up. I'd be tempted to wrap all of the second "startTheApp" function body in a try...catch [14:48] in index.html [14:49] gary_poster: yeah might as well catch everything [14:50] also....locally the headers sort properly [14:50] and it's the same revno [14:50] heh [14:50] I don't suppose coming soon can be set to devel? [14:50] hatch, huh. maybe "running" is the only problem? locally did you try starting with the simulator off and then turning it on? [14:50] abentley: does this ring any bells? http://paste.ubuntu.com/5904369/ [14:50] I didn't... [14:50] I'll try that [14:51] abentley, commented there.. the deployment class has a bit of logic around actually validating the deployment which would be good for a ingest as well [14:51] benji: Usually means elasticsearch isn't running on your localhost. [14:51] rick_h: https://twitter.com/horse_js/status/359687049655238657 rofl [14:52] ^ gary_poster you may also find that funny [14:52] hazmat: Thanks. [14:52] hatch lol [14:52] haha [14:53] abentley: I thought the same thing, but the process is there, it is listening on that port, and "wget -O - localhost:9200" displays a JSON document apparently generated by the server [14:53] gary_poster: simulator off first causes this bug - the data is sorted correctly but the UI doesn't updated appropriately [14:53] will investigate [14:53] cool thanks hatch [14:56] benji: I don't know what would cause that, then. You could try running the exact same command at the commandline. You can get the exact same command by running nosetests without the logging filters. [14:58] oh right......d3 [14:59] I have half a mind to write a d3 wrapper that doesn't look horrendous :) [15:01] ok I am able to reproduce the bug with the simulator on all the time too [15:01] definitely a d3 thing now [15:04] a-hah! [15:11] gary_poster: I'm definitely +1 on logging from the JS. I have done that on other projects before where the JS would file log items in the back end on errors and the like. [15:11] gary_poster: there's been talk of doing oops-tools in charmworld and maybe a JS -> oops tools would be cool [15:11] gary_poster: but for a quick hack, the free tier on something like loggly might work out. There's some exising logger helper https://github.com/loggly/loggly-castor/ and http://loggly.com/support/sending-data/logging-from/application-logs/javascript/ [15:12] gary_poster: it does look like oops-tools does have a charm, though not used it. [15:13] gary_poster: sinzui has invited me to the 1330Z orange standup, which conflicts with our one-on-one. could teknico and i trade 1:1 times? [15:13] ugh, though yea that requires rabbitmq and pgsql to come along for the ride [15:13] rick_h: gary_poster though because this is potentially intranet software - pinging an external server might be a big nono - along the same lines as the analytics code [15:14] hatch: yea :/ why oops-tools is probably the best way to go long term I guess though it makes me sad [15:14] I'd like to pop up an alert saying there is an issue - here is what's being sent - do you want to send....similar to how ubuntu does it now [15:14] at least the interactions are expected that way [15:15] hmm, I was thinking a little deeper than that so that we could alert ourselves to things before they break. [15:15] it's server side and no private data involved. I don't know why we have to ask for permission to send [15:16] we might be talking about two different things [15:16] I'm tralking about js errors in the browser [15:16] talking* [15:16] hatch: yea, why are we asking "can i send this error to a server" on a js error in the browser? [15:16] It's asked in ubuntu because the data sent might contain content from your private file, etc. [15:17] we don't have any of that [15:17] because it'll need to contain the dataset that triggered the error [15:17] if there's an error jfdi [15:17] simply saying 'error on line x' is pretty useless :) [15:17] hatch: on all public data... [15:17] * gary_poster back and reading... [15:18] hatch: right, but you can get a traceback and send it [15:18] there's no need to stop and ask imo [15:18] to send any potential data in the stack you do [15:18] what potential data are we afraid to send w/o permission? [15:19] well prettymuch anything [15:19] hatch: specific please. You're using the gui on jujucharms.com and an error occurs. What data in e.stack are we afraid to send? [15:20] deployed charms [15:20] number of units [15:20] config.js [15:20] on jujucharms.com? [15:20] rick_h, hatch, it's all potentially personal data, *but* [15:20] we can take the GA approach [15:20] that we have now [15:20] specifically [15:20] how is config.js private on jujucharms.com? [15:20] it's not [15:20] but why would you build a tool simply for one usecase [15:20] we send the info [15:21] and if people don't like it, on jujucharms.com, they don't use it [15:21] because we have users hitting issues we can't replicate right now on jujucharms.com and that's the case I'm trying to address asap [15:21] as a tool, we give an option to turn it off [15:21] gary_poster: +1 [15:22] hatch, I think that's entirely in line with our privacy policy, and we already have the warnings/links about this [15:23] I suppose this is all assuming the console error hasn't bricked the app :) [15:24] and allows us to fire data to GA [15:24] hatch: right, but if we implement something all logging should go to it. And we wrap it with console.log in debug and 'send log to remote location' in production [15:24] hatch: thus something like loggly or oops-tools [15:24] I wrote a console.log wrapper a long time ago that did that [15:24] hatch: yep, I think we all have :) [15:24] haha [15:25] mine is locked in a svn repo export.....(plz don't make me install svn just for that) :P [15:25] hatch: heh, I've been trying to find mine in my NAS backup from a few years ago and then figured it was for jQuery and I probably don't want to find it. [15:26] I'd be afraid to find my 3-6yr old JS code [15:26] gary_poster: I get a different popup menu on comingsoon than I do on trunk for build-relation and the like....same revno... [15:26] rick_h: did you see my link from horse_js above? [15:27] hatch: yea, long history there. I find it more sad than funny [15:27] awww :( [15:27] creator of pylons, turbogears, Paste and half the wsgi world of tools, all went to mozilla and went JS [15:28] hatch, popup: yeah I think our makefile has css issues. i will try to kick it [15:28] rick_h: clear indication that JS is a better language :P [15:28] .... [15:28] indication that JS needs more smart devs to make it suck less? imported from the best... [15:29] oooOooOoooo [15:30] well, I should say js 'tools' since they stole a bunch of framework and tool authors from Python to hack on JS tools/libraries. [15:30] rumor has it that Google has moved V8 devs to Dart [15:30] poor devs [15:31] lol [15:31] the two guys that were doing the IO talk on the Dart compiler were from V8 [15:31] I want to say they....wrote V8? [15:31] I can't remember exactly now [15:35] do we have any way to debug the d3 script? [15:35] some way to switch to an uncompressed version? [15:36] hatch, yes...devel should use it [15:36] hatch if it doesn't we have a bug [15:36] yeah that's giving me the compressed version [15:36] we have the uncompressed version around tehre somewhere, pretty sure [15:36] Makyo, any clues ^^^ ? [15:37] Just a sec, let me look into it real quick. [15:39] the d3 source is 7000lines of undocumented code....oy vey [15:40] gary_poster, hatch, we have the uncompressed version from npm, would need to make it available in assets, change the fullpath in modules-debug, and use the compressed version in modules-prod. [15:41] ahh [15:41] we should probably fix that at some point hey? [15:41] hatch, Makyo +1 [15:42] hatch, sure. Just means breaking from our current pattern with modules-prod [15:42] Makyo: if I change this insert() to append() it works but with insert I get a DOM Exception 12 https://gist.github.com/hatched/de5e686fa7028a200396 [15:42] Which is fine, of course, just a new thing for me, is all. [15:43] Makyo: ok well we can leave it for now but maybe we should revisit how we do module loading entirely [15:43] hatch, a wishlist item. It might be good to at least figure out a path forward. [15:43] yeah [15:45] Hm, I might actually be crazy. Maybe it's easier than that. [15:45] Coffee required, though. [15:45] I just changed the file in modules_debug for noe [15:47] Alright [15:47] and found the issue [15:48] well so I thought [15:48] hehe [15:48] I think the d3 api is wrong [15:48] :P [15:48] Check for issues, then, if that's the case. [15:49] oh... [15:49] our version isn't even close to the most recent [15:49] lol [15:49] that could be why the api and the code don't match [15:49] haha [15:50] I mean, the gist code will cause errors because the before argument should return a node, and now it's just logging stuff. Should use .call for that. [15:50] right I added that in....it now returns a string [15:51] but the whole fn is being passed to the querySelect() [15:53] Makyo: I see our package.json says <3 for d3.....is there a bug in d3 v3? [15:56] hatch, rick_h Makyo https://pastebin.canonical.com/94869/ [15:56] hatch, We had a version-freeze earlier this year. [15:56] hazmat: How do you run the tests in the new deployer? The README still says "python deployer/tests/test_deployment.py" [15:56] Before v3 came out. [15:56] right - but I mean was there a reason for this freeze specifically [15:56] gary_poster: uh..so that's ungood [15:57] jujugui call in 3 [15:57] kanban now :-D [15:57] gary_poster: ugh...I know 'why' thats happening but I don't have a proper fix [15:57] hatch, We froze all versions to keep landing branches sane, that was the thing. If you want to do a full QA run and get us up to v3, I've got no problem with that. [15:57] hazmat: But that fails with ImportError: No module named deployer.config [15:57] gary_poster: what was the url at this point? [15:58] our module code isn't pulling in all the required dependencies [15:58] so yui goes and fetches the rest [15:58] there IS a https yui combo service though.... [15:58] rick_h, checking [15:58] hmm, spinner image is also pulled from non-https [15:59] wtf, why is the spin.min.js not in the rollup? [15:59] ugh [15:59] ah, because it's spinning while things load I guess [15:59] yes [15:59] they see me spinnin....they hatin [15:59] lol [16:00] :) [16:00] Makyo: ok I'm going to have to attempt an upgrade because the version we are on does not accept a fn as the second argument to insert [16:00] hatch, rick_h fwiw: plain old jujucharms.com [16:00] no url [16:00] chromium [16:01] jujugui call now [16:01] gary_poster: ok, looking and trying to reproduce. Only one I can repo is the close-orange.png atm [16:03] rick_h, hatch could be from loading devel version yesterday? clear cache? [16:03] gary_poster: maybe [16:03] abentley, python -m unittest discover [16:03] gary_poster: but we shouldn't be doing that in devel either. [16:03] abentley, from within top level of the source tree.. there are other options as well. [16:03] abentley, sinzui could one of you review thes mp: https://code.launchpad.net/~adeuring/charmworld/1202665-nofile-errors/+merge/176418 [16:04] * sinzui looks [16:08] gary_poster, when I export an environment via 'shift-d' any strings such as "on/off/yes/no" are parsed as keywords and not strings. Is this a gui thing or a deployer thing? [16:08] arosales, on call will reply soon [16:08] gary_poster, example is just export a mysql/wordpress env, and then try to redploy with the deployer and errors come up as the values aren't strings [16:08] gary_poster, ack [16:17] robbiew: do you have a few min to do a hangout with a screenshare for this jujucharms.com issue? [16:18] rick_h: when I'm out of this call, sure [16:18] robbiew: ty [16:19] adeuring, r=me with an additional comment. [16:20] sinzui: thanks [16:25] robbiew: calling back, was logged into wrong account. [16:30] rick_h, ben was able to dupe once in incognito mode, and then could not. Makyo hatch and I cannot repro at all in incognito or otherwise [16:30] gary_poster: talking with robbiew now, looking and trying to make sense [16:30] thanks rick_h [16:32] * benji jumps into the escape pod. [16:38] gary_poster: ok, I don't understand how we're starting the app. We're not using the domready event, there's some sort of setTimeout() in there. I think we're just hitting race conditions with the order for3 files getting loaded [16:38] the stuff we're doing in app/index.html seems like it'd be fragile [16:38] rick_h: so it's reproducable? [16:38] hatch: so he had it over and over while he was using a cached file. On a freshly cleared cache it went away [16:40] gary_poster's gotten it once in incognito mode, but only once. I can't help but think it's some sort of race. In his network graph on a failing case the files were coming in on the network tab way out of order of listing in the index.html, which shouldn't matter unless startTheApp isn't waiting for files to load first...and it seems like that's the way it works now [16:40]