[00:14] hatch: Here we go: https://github.com/juju/juju-gui/pull/193 [00:41] huwshimi looking [00:41] lookin good [00:41] I'll do the review in a bit [00:42] huwshimi the ci failed [00:43] hatch: Yeah, was just looking at that. It's as if I didn't get the module-debug.js update... [00:43] you need to add the extension file into merge-files [00:43] bin/merge-files [00:43] you'll see a huge list of them [00:44] Ah I see [00:44] hatch: I've got another change to make before you can do a full review anyway, so hold off on that. [00:44] yes it's sad that I knew these things [00:44] lol [00:45] yeah no problem [00:46] haha [01:13] huwshimi ready for review? [01:14] hatch: Not quite, just adding tests for events [01:14] ok np, I may not get to a review for tonight then [01:15] hatch: It might be done it two mins... [01:15] oh ok [01:15] well ping me and I'll try and get to it :) [01:20] hatch: Just rebase and pushing now. [01:22] hatch: Ready! https://github.com/juju/juju-gui/pull/193 [01:22] ohhh kay [01:22] on it [01:23] Thanks! [01:44] hatch: Just going to have lunch so I'll fix up after that. [01:44] hatch: Thanks heaps for reviewing [01:45] huwshimi no problem - it's a pretty nit picky review :P [01:45] I'm just doing a qa now [01:50] hatch: That's fine, happy to have that kind of review [01:51] cool :) I should do more of them lying on the couch hah [01:51] huwshimi ohh, I'm nto sure if you noticed but we upgraded node while youw ere gone [01:53] hatch: Ah right, means we can move to sass right? [01:53] I believe that was the holdup you mentioned - so I'm taking your word on it [01:53] :P [01:54] hatch: Nice, thanks! [01:54] hatch: thanks for hanging on and reviewing appreciate it [01:54] hatch: but don't run too long [01:54] thanks for the awesome updates huwshimi, I think this will work out much nicer to build on top of [01:55] really nice base [01:56] rick_h_: Great! [01:57] party on! [01:57] rick_h_: I'm going to fix up this branch and then would you be happy for me to get scss working again? [01:58] I guess my next branch to work on is "create machine panel view" which requires the header to have landed. [01:59] But, not sure if I can tackle that without an imp call [02:00] huwshimi: as much as I <3 scss > less the machine view/inspector stuff is priority [02:00] huwshimi: I assigned a small bug your way from luca today or last night if you get a chance to look [02:00] rick_h_: No problems. I'll take a look at the bug. [02:00] huwshimi: and then yea, the machine panel view I think would be next to go, it fits in somewhat with what hatch is working on [02:03] huwshimi: noticed you had hte wrong card there for your task [02:03] swapped those over [02:04] huwshimi: so yea, there's two other machine view component cards after this one. [02:04] huwshimi: but please feel free to add a scss conversion to the slack lane and if you get stuck on something sometime it'd be a cool background task [02:05] OK sure [02:05] night all, sleepy techie... [02:05] rick_h_: Night! [12:27] * frankban lunches [12:36] frankban: thanks for looking into that issue. I'm glad the original assignee has spoken up now [13:26] rick_h_, rails/example-scalable is missing from the web UI [13:26] exists in the store afaict [13:26] jcastro: k, looking [13:27] jcastro: full url? [13:27] https://code.launchpad.net/~charmers/charms/bundles/rails/bundle [13:31] jcastro: added a card to try to get it investigated. I'm out on an intro sprint this week so might be a day/two to get a good look. [13:31] jcastro: nothing obvious wrong, proof's, etc [13:32] jcastro: but it loads on staging so it's something with production and the awesome black box there [13:32] http://staging.jujucharms.com/bundle/~charmers/rails/example-scalable [13:33] cool [13:51] bwuhahaha http://comingsoon.jujucharms.com/:flags:/il/mv/ [13:51] starting to look like something [13:51] that doesn't do anything at all, but it looks :) [14:02] haha [14:03] with these short names we have to be sure we grep for flags.il [14:06] and the fiber connection appears to be working (he said) [14:09] OOoooOoo [14:16] rick_h_: 1.17.6 is in trusty. I am starting quickstart QA on it [14:21] rick_h_, don't forget to remove ~charmers from bundles too! [14:23] ... and it failed [14:24] guihelp trusty users: have you encountered this issue before? http://pastebin.ubuntu.com/7151411/ [14:33] I've run into quite a few odd issues with juju-core in the 1.17.x branches - hoping they all get resolved before 1.18 :) [14:34] hatch: yeah, I am trying to figure out if this should block the quickstart release [14:35] it doesn't look like a quickstart bug [14:35] it looks like a core bug [14:36] hatch: precisely [14:36] asked on #juju-dev [14:39] frankban the first thing they will ask is 'is there anything in the logs' so you might as well check there first :) [14:40] hatch: I am checking if this also affects saucy [14:40] early access "Go In Action" http://manning.com/ketelsen/ looks like there are only two chapters available so far [14:41] rick_h_, does drag and dropping a bundle with multiple stanzas work yet? [14:41] basically, the design people need to get updated pictures for the juju flyer [14:41] george co....stanza? [14:42] jcastro do you mean stanza wrt multiple bundles in one deployer file? [14:42] yeah [14:42] if so, no it's not supported yet [14:42] ugh [14:42] so basically, the rails bundle is undeployable [14:43] well I thought that the charmstore splits them up? [14:43] yeah but the design people are likely using the GUI [14:44] I mean - I was under the impression that the charmstore splits them up so the search results should show multiple bundles in the result list [14:45] oh hey [14:45] does it work on comingsoon? [14:46] when I search for rails there is a single recommended bundle [14:46] right, but the 2nd one is missing [14:46] ahh so it only takes the first one [14:46] rails:example-simple is there, rails:example-scalable is not [14:47] yeah looks like a charmworld feature isn't there [14:47] the gui just shows what it's given [14:50] jujugui call in 10 [14:51] man that call comes up quick now [14:58] jujugui callin 2 [15:07] I was just kicked out of the call. Trying to reconnect. [15:13] afk a few minutes [15:16] benji since you switched to this new camera you have been having a lot of video issues === hatch__ is now known as hatch [15:17] new and unimproved? :) [15:17] hatch: yep (but today's camera was the old one) [15:17] ohh interesting, it seemed to freeze just like the 'new' one [15:18] maybe a trusty driver issue? [15:19] jcastro: yes, it's undeployable atm. We won't have multiple dropping support for a while [15:19] jcastro: we should be able to start looking at it later today/tomorrow. [15:37] new HTC One [15:37] ooooo [15:37] * hatch looks at mine.....looks at the new one [15:48] jujugui: http://jujugui.wordpress.com/2014/03/25/juju-quickstart-1-2-0-released/ [15:48] w00t [15:48] hazmat, marcoceppi: I just updated the juju stable PPA with the backported packages of deployer (0.3.4) and jujuclient (0.17.5) [15:49] \o/ [15:49] Nice [15:50] ahhhh my brain does not work like browser.js [15:50] must....not....rewrite.....routes..... [15:54] frankban: woot! [15:54] frankban: once it hits pypi can you ping james page and look into getting an updated upload to trusty and talk to him about closing out our FFE bug for it [15:54] hatch: :P [15:55] hatch: ignore routes, they don't exist [15:55] it's magic :) [15:55] rick_h_: it's already on pypi, pinged rbasak about that [15:55] as soon as you touch routes you get hit in the head by double dispatch and life sucks [15:55] frankban: ok awesome thanks [15:55] mp [15:55] sounds like we should fix double dispatch :) [15:56] hatch: it's already fixed for you as long as you stay away from routes [15:56] hatch: mission accomplished, plus we need more state than a url/route can handle so you can't get rid of it anyway [15:57] jcastro: that quickstart release removes ~charmers [15:57] jcastro: and we've updated the deploy instructions in the gui and should be release later this week [15:57] I guess I prefer the router to be explicit '/inspector/:service/:unit' for example [15:57] that's fine [15:57] but don't think route, it's state [15:58] right but the route can call a single method instead of one who's 100 lines long and has way too many responsibilities [15:58] which 100 line method? [15:58] *cough* there isn't one *cough* [15:58] sidebar + routeView is over 100 lines [15:58] that's two functions :) [15:58] sidebar is only 4 lines shorter than 100 lines [15:58] :) [15:58] and I admit that the sidebar function can be broken up into smaller bits [15:59] hatch: heh, yea and it's commented to high heaven [15:59] shall I go look at other methods in other bits of the code? 100 lines eh? [15:59] I still think that the router should be the source of truth [15:59] hatch: and that can't happen [15:59] it's not smart enough [16:00] why can't the router call a method which updates the state? [16:00] hatch: we can chat about it if you want. I'll tell you where the router falls short for our uses and why state still needs to be there even in a non-double dispatch world [16:00] because not every thing we draw is/should/can be in the url [16:01] right but anything touching the router is from the url [16:01] what tab is selected in the inspector? How about which tab in the service details popout? [16:01] man, the router isn't official in any other code in the GUI. Why is it NOW a problem? I mean what in the inspector, service view, etc deals with it? [16:01] right, and those can be separate methods which update the state and don't need to touch the router [16:01] right, so forget the route and just deal with state. Have one source of truth. [16:02] if you split up into a bunch of routes with state and async renders for those route callbacks it'll be hell [16:02] I've been down that road with the browser [16:02] that's even before double dispatch [16:03] it's more complex then a todo app :) [16:03] right but right now it's impossible to tell what routes are support or, looking at a url, what is supposed to happen without parsing through many lines of code [16:03] ok, I'll give you that's fair. [16:04] I think a lot of what we are doing can be done with 'middleware' routes and then specific ones with defined methods [16:04] the discoverabiity/etc isn't as easy with routes, but it wouldn't be anyway. [16:04] hatch: right, if we rewrite everything, remove double disptach, and get to some ideal state it might be cool and work out better. [16:04] but it's a LONG way from where the world is now [16:04] but I think we can handle double dispatch with middleware [16:04] and it's not something we've got the bandwidth to fix between now and vegas [16:04] is what I'm saying [16:04] that's what the state does [16:05] exactly [16:05] it already deals with double dispatch as a middle layer [16:05] so why is it so bad to work with? [16:05] I think that the routes should call specific methods to update the state, then a middleware layer to check if it's the same, if it is, then don't next() [16:06] so then we maintain the state funcitonality [16:06] which we both agree is necessary [16:06] but we have meaningful routes [16:08] hatch: maybe, we can talk about it [16:08] hatch: I've got to get ready to head out to lunch with ramm [16:08] yeah np I'm implementing it as it is [16:09] hatch: I don't mean to be a pita, but it seems that rewriting what's working and is well documented and tested and not a complete mental nightmare seems a bit overkill but maybe I'm too close to it [16:09] hatch: we can try to setup some time to look at a proof of concept for reworking it some, but we just spent 2 weeks fixing the inspector to be easier to work with and I don't think we've got the bandwidth to do the same to the browser.js [16:09] yeah that's fine [16:10] it would probably take us at least a week if not two to rewrite this too [16:10] we definitely can't do it before vegas [16:11] Alrighty, rick_h_ and I are afk for lunch [16:24] I still have two more keybase.io invites if anyone wants [16:40] good nuf? https://www.evernote.com/shard/s219/sh/9a098cc5-6ee6-4770-928c-b44856f06eca/4b02fa5abc7f79a5c0266ceb527c9639 [16:42] Makyo do you know if we could have a url for the ghost inspector? [16:42] I'm trying to figure out the best way to update the state and it seems like a url would be the best [16:42] hatch, Not sure I think that's a very good idea. [16:43] It's not a bad one, it's just showing transient local state in the URL (which can be shared) [16:43] so here is the issue...the user drags and drops a charm on the canvas, the drop event comes form the canvas [16:43] So if you have a ghost inspector open and try to share the URL with someone else, it'll fail. [16:43] it now needs to go up to the browser subapp to render the inspector [16:44] Mmhm. [16:44] well...it would open a inspector to deploy that charm [16:44] With no drop position info. [16:44] ahh right [16:44] Or any changes the user has made to config [16:44] the path from the canvas to the browser sidebar is not a clear one :) [16:44] Yeah, that's fair :/ [16:44] Events? :D [16:44] * Makyo ducks [16:44] could fire an event but that's a long way [16:44] lol [16:45] could pass a method down [16:45] but not sure if that's any better than an event [16:45] it's like using a really long stick to poke a switch heh [16:46] updating the url could 'just work' but I see what you're saying [16:46] we could include positional information in the url [16:47] but I guess that would be weird back-button functionality [16:48] we could pop it out of the history heh [16:48] ok I think I know what i'll do [16:49] Using the URL as an event dispatcher? :P [16:49] lol [16:50] I'll move the inspector creation code from environment.js into browser.js and then fire an event from the canvas > app > browser [16:50] the event targets should allow that pretty trivially right now [16:50] oh...wait [16:50] there are a bunch of events from the canvas to the inspector [16:50] hmmm [16:52] we need a better transport mechanism [16:59] events it is [17:13] we need a indexdb juju environment so we can test this new inspector stuff without being in a real env [17:14] it's impossible right now to see /inspector/:service work in the simulator [17:14] I wonder how hard that would be.... [17:14] hmmmmm [17:14] probably not horrible [17:18] rick_h_: re the rails bundle error. If trunk is working correctly and you have that running locally can you help us get a screen shot of the rails bundle with all green? [17:19] rick_h_: the need here is to get a design a good screen shot for the flyers going to GopherCon and OSCON [17:23] arosales he is out for lunch atm [17:23] should be back rather soonish [17:24] hatch: thanks for the info. [17:48] heh - showing the service relation menu has been creating inspectors [17:48] stealth bug.... [17:53] back [17:53] squished [17:53] kadams54 good lunch? [17:54] Yeah. Yelp did not lead us astray. [17:54] I get left overs [17:54] Chinese leftovers? [18:00] arosales: k, yes. We can get a screenshot. Will take a few [18:01] hatch: I don't think that the ghost inspector would be url-able? [18:01] kadams54 home made stir fry...so sort of asiany [18:01] hatch: sorry catching up on log [18:01] rick_h_ yeah I've done some uglyness to get the topology into the browser [18:01] I think it's just something we will have to deal with [18:01] hatch: k, these are the pain points for sure. [18:01] it's all commented up [18:02] hatch: this is where I was expecting the main work in the move to be [18:02] hatch: k [18:02] rick_h_ current wip https://github.com/hatched/juju-gui/compare/prep-charmbrowser?expand=1 [18:03] in case you were curious [18:03] hatch: k, looking while I get a gui up for arosales [18:03] rick_h_: thanks. I also sent a mail with instructions and needs [18:04] jcastro: ^ [18:04] rick_h_, we need one of each bundle, mongodb:cluster and rails:example:scalable [18:05] jcastro: ok, but you've got the mongodb cluster right? [18:05] rails:example-scalable rather [18:05] not with the new sidebar no [18:05] new sidebar? [18:05] on the left [18:05] the inspector [18:05] well that doesn't exist yet [18:05] that's WIP [18:05] yeah it's for the flyer so we want it to be as close to the future as possible [18:06] jcastro: k [18:07] rick_h_: in the email Spencer had some examples of the sidebar bits [18:07] arosales: yes, he's designing stuff but we don't have it implemented. It's what we're doing for 14.05 right now [18:07] arosales: do you have this email? I'm not seeing it [18:08] arosales: sorry found it [18:08] rick_h_: email subj = "Fwd: Images for flyer" [18:09] arosales: yes, there's no pic in there though. I don't know what spencer is sending you [18:10] rick_h_: sent w/ attachment [18:10] heh yea see it. Those are pure design mock ups. I can't recreate that with a bundle and such and live data [18:13] arosales: jcastro http://uploads.mitechie.com/lp/rails-bundle-screenshot.png chop and use it as you see fit. [18:13] arosales: jcastro since it loads on staging I just deployed the gui into a lxc environment and changed the config for "charmworld-url" juju set juju-gui charmworld-url="http://staging.jujucharms.com/" [18:13] for reference if you need something like this and I'm afk/etc [18:14] rick_h_ if you zoom out does it show the bottom of the bundle vis? [18:15] rick_h_: ok so jcastro you should be able to do this for mongo with the config settings [18:15] that's one heck of a bundle heh [18:15] arosales: we shouldn't need it for mongodb. That one is ingested and working fine [18:15] you can do that on comingsoon or jujucharms.com [18:17] yeah mongodb isn't a problem [18:17] it's rails that was the problem [18:18] jcastro: but you still need the new sidebar for mongo, which sounds like we can get a comingsoon [18:18] arosales: that is not true [18:19] rick_h_: /me just going off what jcastro sayd he has in terms of side bars [18:29] rick_h_: if we delete a branch from launchpad will the charm be removed from charmworld? [18:29] marcoceppi: no, but we're getting a removal UI in charmworld to help with this [18:30] marcoceppi: it's committed but not deployed yet [18:30] marcoceppi: should get a deploy out this week with it [18:30] rick_h_: anything we can do in the mean time? [18:30] marcoceppi: what's the details around it? [18:30] * hatch stepping out for some lunch errands [18:30] bbiab [18:42] rick_h_, fixed that cassandra README issue, I'm going to file a bug on charm-tools to check for that [18:45] jcastro: k thanks. Sorry to punt on it [18:46] it's fine, it's a subtle thing that we should be enforcing in policy anyway [19:06] rick_h_ I'm replying to your comments - which one is `il` again? lol (the problem with too short flags) [19:09] Inspector Left [19:10] hatch: ok cool, chat after you go through them? [19:10] ohh [19:10] ok then yes [19:10] :) [19:10] hatch: sorry, pm'd you in invisible space :) [19:10] ahh dinging all over the place [19:11] rick_h_ yep, you made some good points here [19:13] rick_h_ https://plus.google.com/hangouts/_/76cpj84oalco0dv6t5k2st3lgk?hl=en [19:14] there is a warning on ABS glue "do not smoke" [19:14] w t h [19:19] hatch: joining [19:48] rick_h_ what article is jc talking about? [19:48] on the tweeters [19:49] hatch: sec otp [19:51] sure np [20:07] rick_h_ mentioned a utility for quickly injecting HTML fixtures into the container; I need a reminder what that is? [20:08] kadams54: makeContainer [20:08] thanks [20:21] jujugui feeling wretched, going to sit on the deck for a few, won't be around for pings. [20:21] okee cya [20:21] rest up [20:21] Makyo: hope you feel better [20:25] hatch: benji did you guys have the LoC numbers you were chatting about the other day still? [20:26] actually, should have those in the irc log [20:27] not sure what you're referring to [20:28] hatch: weren't you and benji looking at how many lines of code was in the gui [20:28] hatch: oh, your blog post! that's right [20:29] ohh yeah [20:29] :) [20:29] I can find them in my IRC log, but apparently you found them [20:29] thanks guy, I just nabbed them from hatch's blog post [20:29] guys [20:29] bah [20:29] EOD bring me home [20:57] Ditto [21:59] man the internet is trippin that FB bought Oculus [22:02] morning huwshimi [22:02] Morning [22:08] rick_h_: Do you know what the card "create machine panel header view/widget" is? It sounds very much like the card I just completed. I know you switched them over because I took the wrong card. [22:15] hatch: Any ideas ^ [22:15] umm looking [22:16] not a clue [22:16] they look the same-ish [22:17] :) [22:18] huwshimi the blocked card in Project 1 is no longer blocked [22:18] you could do that? [22:19] hatch: Yeah, that's my plan, I just wanted to know if I should do that other card first as it seems related... [22:19] yeah I can't figure out what it's pointing to that's not what you just did [22:19] I don't see any other 'header' in the mockups [22:20] yeah. [22:21] hatch: Your official EOD is not for a couple of hours right? [22:22] 38mins [22:23] huwshimi: that one is the header control in the machine view panel [22:23] huwshimi: that's at the top of all 3 columns in the machine view [22:23] huwshimi: let me know if you want to chat on it [22:23] there is no header for the three columns [22:24] rick_h_: Yeah, an imp call would be good. [22:24] rick_h_: Want me to invite you? [22:24] mind if I join? [22:24] huwshimi: k sec [22:24] sure [22:24] ohh NOW i see the header [22:25] * hatch doesn't think this is a very good ux [22:25] * hatch hopes he is reading it wrong [22:25] * hatch probably is [22:25] huwshimi: link? [22:26] Trying... [22:26] he has to invite bcus he is from his tablet [22:26] k [22:26] rick_h_: https://docs.google.com/a/canonical.com/file/d/0B5yaFXSrLF38aVk4ZXJZY0tJZWJTUy1GVXlScmZRS21rUFJv/edit [22:43] I wonder if the machine view would be a good candidate for another instance of the viewlet-manager. With the header as a view and each column could be it's own view [22:44] then it would be another `new machineView()` to make the whole thing [22:46] that can be pieced together at a later time [22:57] hatch: What approach would you take to get other views to render to the new content panel? [22:58] maybe now would be a good time to do the viewlet manager [22:58] hmm [22:58] let me stare at this mockup for a bit [23:00] ok so I have a different idea on how to do this [23:01] each column, including the header is a view (it will likely share a bunch of code via extensions) [23:01] those views would be rendered and instantiated by a viewlet-manager instance much like the inspector instances are [23:02] there would be a 'right hand panel' subclass of viewlet-manager and then the machine view and charm details would subclass that again [23:02] (identical to how the inspector viewlet managers work) [23:02] yep that's how I'd do it [23:03] ^ huwshimi does that mean anything to you? you weren't here for that stuff :) [23:03] hatch: It doesn't mean much :) [23:04] hmm ok ok - well... [23:05] I would like another opinion on this before I send you down this path [23:05] hatch: we can take the view that huwshimi has and work with it. The viewlet-manager idea is interesting. I'm not up on what's left in the manager vs not so we should look into it [23:06] hatch: Well, I understand what you're saying, I just don't know how to implement it :) [23:06] hatch: so I'd suggest huw just work on the skeleton views [23:06] and then we'd pull it in/incorporate for full interaction/switching/etc [23:06] right....ok umm [23:06] * hatch thinks [23:06] hatch: but I don't think the viewlet manager would do well with multiple views available at the same time on the same slot [23:06] hatch: as it is now [23:06]