[12:10] sorry for the noise, connection flakiness due to bad weather here [12:30] hey gary_poster, I have a non informational bug report with no debug content [12:30] I tried to deploy this last night and it wouldn't through the GUI http://jujucharms.com/~marcoceppi/precise/discourse [12:31] had no problems deploying haproxy and postgres, but this specific charm would not. The error was vague too, something like "there was an error" and no explanation [12:31] jcastro, ack. thanks, we'll give it a whirl. [13:06] hey benji, are there default juju deployment constraints? I don't think so, but checking. [13:07] gary_poster: default values or a default scheama? [13:07] values benji [13:07] nope [13:07] cool thanks benji [13:09] hey luca. We don't have access to the web team dropbox so we don't have Jaime's assets. Will you share those with us another way, or do you have another plan? [13:10] gary_poster: I'm just setting up a folder here: https://drive.google.com/a/canonical.com/folderview?id=0B7XG_QBXNwY1V3B3dDNvYXJGRE0&usp=sharing [13:10] cool thanks luca. so you will send out an email with that and the new flatsies url? [13:11] gary_poster: Yeah, I'm just trying to work out if there are any missing assets from the /psd [13:11] sounds good. thanks again [13:16] benji: can you +1 real quick, and heads up for your branch that it's coming https://codereview.appspot.com/10610043 [13:16] * benji looks [13:16] jcsackett: is https://codereview.appspot.com/10609043/ ready for eyeballs? [13:18] rick_h: +1 [13:18] rewrite it all in webgl! http://microsoft-news.com/webgl-spdy3-new-dev-tools-more-confirmed-for-ie11-in-win-8-1/ [13:18] benji: thanks, sorry it didnt' have cleanup when you hit it. [13:18] no worries [13:19] and spdy our servers! (boo no mod_spdy in the repo) [13:38] Can anyone here tell me how assets should be delivered for the bundle icon? See here: https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1MlVkNWxHQVJ2UDg/edit [13:40] gary_poster: ^ [13:45] luca, will you always want the black and orange thing behind the main icon? Or are these assets that we want bundle authors to be able to customize (colors esp.)? [13:46] gary_poster: I was thinking that it would be awesome to let them customise the colours but if we can't do that then just the orange and brown is ok for now. [13:48] luca ok. short answer is, for now, svg. It would be great if there were a super simple way for charm authors to change colors and add their primary icon, but if they just jave to use inkscape or illustrator or something, so be it [13:48] * gary_poster moves to other computer... === gary_poster is now known as gary_poster|away === gary_poster|away is now known as gary_poster [14:06] * gary_poster switched [14:14] hey sinzui. were you ok with being responsible for getting back with Matt Wedgwood about getting the GUI deployed, and the schedule I proposed, including getting an up-to-date version of the GUI deployed on the prod machines this week? [14:15] gary_poster, yep, and because of the squad changes, Much of the work will be with those doing webops this month [14:19] cool thanks sinzui [14:22] rick_h, abentley have you heard back from dan with flight approval yet? If not, sinzui would you like me to ping him about it? the longer we wait the more it costs [14:22] gary_poster: yes. I have updated the spreadsheet with my auth number. [14:22] gary_poster: I just got the email in the last 20min and sent my email off to corp travel just now [14:23] gary_poster: with luck will have info before EOD [14:23] yay abentley and rick_h, thanks. abentley, do you think before EOD will work for you as well? [14:24] bcsaller, when you get in, you're the only other one. do you not have requisition approval yet? If so, tell me who you sent it to and I'll ping them. [14:24] gary_poster: Not sure yet. Auth had the wrong departure date, so I've emailed events@canonical.com to ask what to do. [14:25] ah ok abentley, I will ping sarah about that, thanks. [14:27] rick_h, ping me when you are ready to hangout [14:27] gary_poster: did we make a decision on bundle? [14:28] jcastro, it looked like bundle won. I'll clarify with mramm on juju-dev right now. since he was +1 anyway I'd be surprised if it were anything other than "bundle." [14:28] :.( [14:29] :'''''( [14:29] :{{{{{{{{( [14:29] don't be sad, bundle is fine! [14:29] *wahhhhhhh* [14:30] lol [14:31] * hatch sets up a google alert for stack vs bundle questions [14:31] haha I'm horrible [14:32] oh hey guys, the juju-gui readme appears to need updating [14:32] juju deploy cs:~juju-gui/precise/juju-gui [14:33] you want that to be from the store instead now right? [14:33] yeah jcastro thanks [14:34] btw I asked mramm in privmsg. didn't feel like potentially stirring up hornets nest on dev when we are supposed to be settling on name. :-) [14:36] haha [14:41] jcastro, hatch, it is decreed: bundles. [14:41] how unfortunate! [14:42] on the bright side, we can move on. :-) [14:42] I agree with your concerns and others [14:42] :) [14:42] but better to get back to getting this done [14:42] gary_poster: we need the readme for the gui fixed by Monday btw [14:42] jcastro, ack, will do. [14:44] gary_poster: is the old_new interface available? [14:45] gary_poster: when someone downloads juju what interface do they see? [14:45] oldnew [14:45] luca, hatch is correct [14:45] this one: https://docs.google.com/a/canonical.com/file/d/0B7yNWRv_QU7WYzB4RU9EZTZVc0k/edit [14:46] hatch: gary_poster ^ [14:46] luca, more or less. that has some never implemented bits like the new service icons [14:46] yeah [14:46] gary_poster: mark has a keynote tomorrow [14:47] gary_poster: and is asking for an image of Juju [14:47] gary_poster: Should I send him the dark grey one? [14:48] luca, do you know what the conference is? [14:51] luca, I would send him the old one (set a few services up on http://uistage.jujucharms.com/ , for instance) and the oldnew one (http://uistage.jujucharms.com:8086/). I'd suggest that you recommend the old one for publicity because of the OSCON launch, but mention that the oldnew one is much more attractive even though it is transitional, so you were offering it as well if it were more appropriate for the audience. [14:52] gary_poster: I phoned Ale and she said the same thing so I'll sort out the images now [14:52] cool luca [14:53] gary_poster: last night bcsaller and I had a discussion about merging the controllers for the ghost/service view and using composition to plug in methods to allow for easier testing so that's why that branch hasn't landed yet and I have modified the cards on the board [14:54] we actually had a rather long discussion but we were really arguing semantics in the end.....so it was a good discussion haha [14:54] hatch, ok. when's the new landing target? :-) [14:54] EOD or sooner (depending how many reviews I have to do ;) ) [14:55] cool [14:56] abentley, hi. talking to sarah. how far off was your departure date in the authorization? days? months? years? [14:57] gary_poster: 1 day. Ticket ID: [Canonical Events #89] [14:57] ack thanks [14:58] abentley, answer is to proceed. [14:59] gary_poster: Okay. [14:59] thanks abentley [15:05] benji, thank you for landing dnd deploy. cool. :-) (1) did Makyo look at whether transferring x/y position was easy with you, or is that still an open question? I'd like to know what additional card to make, and how to schedule it. (2) when you drag from the token, you see the token as the drag marker. when you drag from the full charm box (token + name + downloads) you see the full charm box as the drag marker, [15:05] but I think it would be nicer to still use the token. Was this already discussed? If so, and the question was based on UX rather than a technical issue, was Luca involved? [15:05] gary_poster, not yet, but I can check real quick. [15:06] cool thanks Makyo [15:07] gary_poster: (1) I was just typing up a question for Makyo; (2) It wasn't discussed. I figured seeing the thing you dragged made sense so it didn't occur to me to do otherwise. [15:08] benji, cool thanks. :-) luca do you have time to have an opinion on #2? Is it clear, or would you like at example? You can play with this on http://uistage.jujucharms.com:8086/ [15:09] luca, to be clear, I'm fine with deferring to you on this. I'm just raising the question. [15:10] note that for case (2) the thing being dragged is still the charm token, it is the case that the token just has more/different data in it [15:14] benji, ack [15:15] benji, d3.mouse(this) will give you coordinates of the drop on the screen. This doesn't take into account panning. You'll have to either add two arguments or just retrieve arguments[1] (arguments[0] will be undefined) in order to get the service module. From there you can get the current translation with var topo = module.get('component'), translate = topo.get('translate'), scale = topo.get('scale'); [15:16] gary_poster: benji I can drag to canvas (thats sweet!) but it doesn't show me any token or anything? Should I be seeing anything at the moment? [15:16] luca: yea, looks like it shows and works in FF and not in chrome [15:17] luca, when you are dragging, you should see either a token or the full box [15:17] benji, I believe you'll have to multiply both items in the coordinate pair by scale (I'm doing this in my head; so I may be wrong) [15:17] oh? [15:17] wfm [15:17] on chrome [15:17] Works for me. [15:18] oh weird [15:18] and it worked for me locally on chromium and firefox; looking at :8086 now [15:18] it works for me now too.... [15:18] chromium is happy [15:18] probably cache issue then [15:18] firefox is happy too [15:18] wfm on chromium [15:19] on chrome (official) dev level here and it doesn't show. [15:19] oh I see what the issue was [15:19] If I drag from the token on ceph it shows a broken image [15:20] same with mysql [15:20] and wordpress [15:20] wfm on firefox but I only ever drag the box, never the token [15:20] gary_poster: yea, same here [15:21] luca, don't know, can't dupe. any messages in the console? [15:22] rick_h, same for you--broken image? [15:22] rick_h, you on os x? [15:22] if I drag from the token I get the full image, always [15:22] gary_poster: I'm on linux on chrome dev channel. It's not a broken image, but a document placeholder image. [15:22] if I drag from the icon I get a broken image [15:23] luca, what do you mean by token and icon? [15:23] I'm seeing something simiar in firefox. *Some* of the tokens show when dragged from the image, some don't. They all work either way though. [15:23] I'm happy to share screen with someone to validate [15:23] hangout-a-palooza! [15:23] heh [15:23] ok [15:24] my network may be sucking. can try guichat luca [15:24] correction, the behavior I am seeing is in chromium [15:25] I'll address this in my follow-on (ghost positioning) branch. === matsubara is now known as matsubara-lunch [15:30] jujugui: can i get a second review of https://codereview.appspot.com/10609043/ ? [15:31] jcsackett: sure [15:31] bac: thanks. [15:31] benji, rick_h could I have you guys in guichat for a sec? [15:31] gary_poster: sure thing [15:32] thanks [15:32] gary_poster: sure [15:32] thanks [15:44] done jcsackett [15:45] thanks bac. [15:46] ugh.....there is nothing more irritating than tracking down event errors [15:47] hatch: tell me about it... [15:48] hatch: meh, it's what tracebacks are for :P [15:48] anyone up for a second review of https://codereview.appspot.com/10605043 ? [15:48] its like 'oh you want a traceback....ha, ha, hahahahaha' [15:48] rick_h: that's the thing - event tracebacks don't go back past the handler :) [15:49] hatch: I guess depends on the event. I've gotten some [15:49] in this case the traceback stops in YUI event land... [15:49] the cleanest, easiest to follow code....ever [15:49] :P [15:50] jujugui call in 10, Kanban now [15:50] oh hatch! you were suposed to run yesterday and I stepped on you! [15:51] please remind me when it is your day and I will be quiet :-P [15:51] haha it's ok you were on a roll and we were behind :D [15:51] :-) thx [15:52] ls [15:52] oops [15:52] hehe [15:52] I use ll which is aliased to ls -al [15:52] I prefer the layout :) [15:52] you cannot be on a roll when you're on a rock, not enough space to dance ;-) [15:53] not enough *room [15:55] hey teknico you landed add/remove relation? oh, still waiting on second review. anyone agree to do it? [15:56] gary_poster, teknico: I'll do it [15:56] gary_poster: nope, just asked for it [15:56] frankban: thanks [15:56] thanks frankban [15:57] guihelp: you run make test-server, it says one failure, there are no failures on the page. what do you do? :-) [15:57] look closer [15:57] teknico, hmm, maybe leave the console open with break-on-all-errors? [15:57] teknico: maybe check the js console? [15:57] how much closer? :-) [15:57] thiiiiiiiiiiiis close [15:57] but yeah, open the console, break on errors [15:58] like Makyo said [15:58] jujugui call in 2 [16:00] Makyo: hatch, where's the command to do that? [16:06] gary_poster: finishing up the flight setup, info is in the spreadsheet [16:06] awesome [16:07] I'm not looking forward to merging this branch bcsaller hah [16:12] how does insurance work with zipcars? [16:13] can I as an international traveler get one? [16:15] gary_poster: you might want to check your power setting on your wifi router - I used to have bad connections outside too, then I upped the power setting and it's much better [16:15] bcsaller, fwiw, this is 1.1 miles away and I think it is awesome. other options but this is my fave. http://www.happycow.net/reviews.php?id=27049 [16:16] gary_poster: cool, thanks [16:16] hatch, it appears to be that linux doesn't swicth from two routers providing the same network very well [16:17] so if I start linux downstairs, it's not happy upstairs and vice versa [16:18] os x is fine [16:18] gary_poster: ahhh ok ok [16:21] gary_poster: any idea of this hotel will have good wifi? [16:23] hatch, has wifi, nobody complains :-) http://www.tripadvisor.com/Hotel_Review-g49463-d3527157-Reviews-Hampton_Inn_Suites_Raleigh_Downtown-Raleigh_North_Carolina.html [16:23] I suppose that's all one can hope for :) [16:24] looks like a nice place [16:24] gary_poster: is there a better design resource i should be using than the wireframes we looked at? [16:25] bac: what do you want to see? [16:25] bac, if new wireframes are not in the folder luca mentioned a few hours ago we can ask him [16:25] unicorns......pick unicorns....... [16:25] rofl [16:26] gary_poster: i thought there was mention of 'visual design' documents vs wireframes. (hi luca!) [16:26] bac: visuels, wireframes and assets can be found here: https://drive.google.com/a/canonical.com/?tab=co#folders/0B7XG_QBXNwY1V3B3dDNvYXJGRE0 [16:26] bac, see https://drive.google.com/a/canonical.com/?tab=co#folders/0B7XG_QBXNwY1V3B3dDNvYXJGRE0 [16:26] visuals in one folder [16:26] thanks [16:26] wireframes in other [16:27] luca: i'm doing charm settings page. [16:27] luca, I'm telling folks that we will need a scrollbar for the whole inspector too, despite images. Agree? [16:30] bcsaller: review done [16:31] hatch: thanks [16:34] gary_poster: there is a scroll bar on this image: https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1VnJrN0ppUHc0bk0/edit?usp=sharing [16:34] everybody STAND BACK while I SHATTER the One Thousand Tests barrier! [16:34] w0000000 [16:34] teknico, lol [16:35] gary_poster: the only bit that scrolls is unit area [16:35] gary_poster: and also the settings page [16:35] luca whole thing will need to scroll [16:35] arbitrary number of alerts [16:36] or have you verified that the minimum pixel size to get everything in is OK? [16:36] yeah but we was wondering if for the post-rep inspector only the light grey area scrolled [16:37] given, say, two Landscape alerts at top plus upgrade charm, and 4 or 5 alerts at bottom, which feels like a reasonable extreme [16:37] pretty much that, we talked it through and felt that since the scale units area is collapsable then it should give more than enough room to view units [16:38] bcsaller: ohhhhhhh alright you can leave format in there :) [16:38] Makyo: share a cab on the 14th? [16:38] hatch, Sure. [16:39] luca, what's the pixel height of the inspector with, say, 5 units showing and, say, 8 alerts showing? [16:39] benji: share a cab on the 20th? [16:39] 5 units: I mean the unit scroll area is 5 units high [16:40] hatch: what time do you want to leave? [16:40] I'm not sure how far the hotel is from the airport....but say...6:30? [16:42] gary_poster: the view we work to is a height of 768px, generally talking in that we should be able to fit enough information, the user has the option of minimising all of the Scale unit area so they can have more room if needed. [16:42] hatch, 12 or 13 miles; 20-25 minutes [16:43] my flight takes off at 8:00 so that would cut it closer than I like. I'd be fine leaving at 6:00 (assuming the airport is about 15 minutes away), but that may be too early for you. [16:44] luca, but if it is not minimized and inspector is too big for height then what happens? it simply goes beneath bottom of screen? [16:45] gary_poster: no, the bottom always sits 20px above the bottom [16:45] luca, guichat? maybe faster, and not making sense to me yet :-) [16:46] gary_poster: sure [16:46] thx [16:46] benji: 6 would be fine [16:46] cool [16:50] bcsaller: the prototype on the ServiceInspector controller isn't ever used is it? getName, bind, render etc [16:50] hatch: looking [16:51] hatch: facade methods previous, don't recall taking them out of the control path though [16:52] ok I don't see them ever being called - I'll look further [16:59] jujugui fwiw I marked the scroll card as blocked. luca is going to consider what behavior he wants. Basically, for now continue as we said on the call: ignore the fact that the inspector gets too big. [16:59] "wow that's one big building.......what building?" [16:59] :) [16:59] :-) === matsubara-lunch is now known as matsubara [17:18] bcsaller: yeah I was just overwriting some stuff that I shouldn't have been, almost ready to propose with the new changes [17:18] hatch: great [17:18] I THINK I like this better [17:18] heh [17:19] that's a lie...I do [17:23] good :) [17:24] proposing now.... [17:24] * hatch grabs some eggs to cook on computer while tests are running [17:26] hmm it failed.... [17:27] trying again hoping it was just launchpad being wako [17:29] bcsaller: https://codereview.appspot.com/10565043 [17:37] hatch: reviewing [17:37] thanks - I still need to add comments and the like [17:37] but I wanted to get this out there asap [17:48] Makyo: with your new branch - I would have to double click the service icon to open the inspector? [17:48] hatch, single click works. [17:50] hmm ok this will not work with the new single controller [17:51] hatch: what won't? [17:51] you need to pass a considerable amount of data into it... [17:51] not just the db [17:51] so possibly another layer of abstraction is needed [17:52] What won't work? [17:52] showing the service inspector [17:52] it needs to know at that point if it's a ghost or not, and then send the appropriate config to the new controller system [17:52] Why not? [17:53] Where's the difference, though? It's the same code as the double click method. All of that is available in both locations. [17:53] yeah in trunk that's fine but not once this lands https://codereview.appspot.com/10565043 [17:53] not your fault - I'm just pointing that out... [17:53] I'm being slow, I don't see the issue yet [17:54] There are already comments (your comments, I believe) to that effect. Is that not just part of working incrementally? [17:54] there isn't an issue in your branch [17:55] but there will be an issue as soon as I land mine - which we'll have to possibly solve by an abstraction layer to not have to pass the complex configs around [17:55] sorry I wasn't clear :) [17:55] Ah, okay [18:21] hey gary_poster [18:21] I'm documenting the submission process [18:21] we noticed the export format is yaml instead of json? [18:21] jcastro, on call but will follow when I can [18:21] jcastro, yes, that's what deployer uses now [18:22] oh ok, we were just curious, thanks [18:38] hatch: got a sec to chat? [18:38] I do [19:00] Makyo, hatch, I dunno what the story is about how you want to handle Makyo's branch, but as is it LGTM [19:00] gary_poster: yeah I meant to actually LGTM it [19:00] but forgot to hit send :/ [19:01] :-) ok, send it and he can land it [19:01] how much more work for you hatch? [19:01] it's done [19:02] gary_poster: https://codereview.appspot.com/10565043 the final version [19:02] I'm just merging trunk right now and dealing with the conflicts [19:02] then I'll submit [19:03] which are now resolved [19:03] soooo I can submit it whenever [19:05] awesome hatch :-) including Makyo's changes? [19:05] 'cause IIUC his change would be tricky with yours [19:06] it will break [19:06] but the proper fix to that is a follow-up branch that ben and I chatted about a few minutes ago [19:06] so maybe he shouldn't land that [19:07] and we can implement that fix in the follow-up [19:07] gary_poster: can you see these diagrams? i can only open one or two: https://drive.google.com/a/canonical.com/?tab=co#folders/0B7XG_QBXNwY1NEtGaHJYZGM4enM [19:08] hatch ok. please coordinate with Makyo? [19:09] bac, yes I can see all of them [19:09] gah [19:09] Makyo: don't land your branch :) "the lgtms are a lie" [19:09] heh [19:09] I thought someone might get that joke :) [19:09] i get a google frownie [19:09] cake :) [19:09] You are so lucky lbox submit failed. [19:09] lol [19:09] :-) [19:10] bac: they work here too [19:10] bcsaller: yup :D [19:10] well la-tee-da [19:10] maybe one of you could fax them to me [19:10] lol [19:10] ok I'm submitting my branch now [19:11] oh, and now they work... thanks goog [19:14] the mocks on that link are pretty cool [19:14] I'm going to grab some lunch bbiab [19:31] Which juju-gui charm do we want to use to deploy to production? ~juju-gui or ~juju-gui-charmers. The later is older, but you might see it as stable to the former development charm? [19:31] gary_poster, bcsaller ^ [19:31] ~juju-gui-charmers is the released version. [19:32] sinzui: ^ [19:32] ~juju-gui is devel [19:32] fab. Thanks bac. are there plans to update the stable charm this week? [19:33] that i don't know [19:33] sinzui, yes, simply to update the README at least [19:33] i mean, yes [19:33] :-) [19:33] bcsaller, branch LGTM [19:33] gary_poster, because it talks about the dev charm? :) [19:33] sinzui, yes :-) [19:34] gary_poster, I want to tag stable so it is clear what I want in production. I will do an update to the charm and submit it for review. [19:35] sinzui, perfect thanks. Will that include a drive-by README fix? Would be lovely, but not necessary [19:35] understood [20:02] bcsaller: lgtm'd let er rip! [20:02] after gary's changes of course :) [20:26] hatch: you have a minute for a chat? === BradCrittenden is now known as bac [20:26] I do [20:26] cool [20:26] guichat [20:36] bcsaller: have a second to join our chat? [20:47] Makyo, I'd like to get the remove service branch landed. I know that means reconciling with hatch's landed changes. are you already focused on that, rather than the unit count controls? [20:48] gary_poster, yes. [20:48] yay thanks Makyo [20:48] gary_poster, mostly works, but quick question for you and hatch [20:48] cool [20:48] ahhhhh [20:48] there are going to be soo many conflicts haha [20:49] well, his branch wasn't *that* big :-) [20:49] There weren't any, just updating the showMenu code. [20:49] cool [20:49] Actually, give me a second to check on this behavior w/o the inspector flag. [20:49] k [20:50] Makyo: ok you will need to pass in the config which is in views/topology/service.js:1353:1359 [20:50] but that's only for the service view, the ghost one is more complex [20:50] hatch, I promise you that it is exactly the same code as double click. Pinky swear. [20:50] lol [20:50] it can't be [20:50] dbl click calls show_service [20:51] you're in showServiceMenu [20:51] hatch, yes. And if the serviceInspector flag is set, I'm doing exactly the same work. [20:51] In fact, I could make the branch a one-liner and just call show-service. [20:51] yes - do that [20:52] your code will _not_ work with the new controller [20:52] hatch, It dooooes I promise D: [20:52] see the new code in show_service [20:52] it cant lol [20:52] * gary_poster sighs [20:52] hatch, the code in showServiceMenu is LITERALLY copied directly from showService. [20:52] hey hatch, why dontcha wait on his branch [20:52] :-) [20:52] Makyo: yes....the OLD show_service [20:53] haha [20:53] or have a guichat? [20:53] but this is low on productivity :-) [20:53] Very, very low. [20:53] ok ok land it [20:53] I'll put show service in there and re-propose. [20:53] hatch: quick chat again? [20:54] hatch, there's also a review process :-P [20:54] bac: there [20:54] I'm not saying there is anything wrong with your code Makyo - but once you merge it in, it will fail [20:54] :) [20:54] hatch, part of merging is resolving conflicts. I merged, I resolved the conflicts, it works. [20:55] I just want to be belieeeved. But show-service works too, and has less code dup in the end, so I'll just do that, yeah? [20:55] Makyo, propose it. :-) let's give it a whirl [20:59] lol [21:01] Makyo: perfect :) [21:04] We good? :) [21:04] oh we goooooood [21:05] Gonna land, then, so I can count units. [21:05] :) [21:05] thanks [21:07] ok I'm not entirely sure what to do next here [21:07] ahh the switching of the inspectors [21:08] bcsaller: near landing that event detach code? [21:08] hatch: the first submit hit a conflict, doing it now for real [21:09] gary_poster: re 1194866 - the error message was just a canned message - Makyo brought up in a review that the new code should pass the real message through [21:09] bug 1194866 [21:09] <_mup_> Bug #1194866: Cannot deploy http://jujucharms.com/~marcoceppi/precise/discourse from GUI [21:09] so just fyi at least the error messages will be better soon [21:09] hatch, ah cool [21:12] bcsaller: ahh cool - I just wanted it for this next branch [21:13] oh fyi the latest firefox (22) runs our tests about 6% faster on average heh [21:13] it's still about 14% slower than chrome though [21:14] hatch: branch landed [21:14] these are my totally unscientific tests :) [21:14] thank yaz [21:14] man we are iterating fast on this codebase haha [21:16] yay us! [21:16] I'm really glad this isn't svn haha [21:16] on* [21:16] :-) [21:21] gary_poster: I 'add' a service then click 'cancel' in the ghost inspector, does the ghost dissapear? What if I click the 'x' ? [21:22] hatch, lemme get wireframes open 1 sec [21:23] I guess the wireframe doesn't have a cancle [21:23] cancel [21:23] just a save... [21:23] which I guess would keep the ghost there [21:23] hatch on wireframe...uh-oh [21:24] I think my wireframe version is a little old [21:24] hatch on wireframe, we used to have a trashcan [21:24] this *used* to be the answer: [21:24] save and "X" are equivalent [21:25] click the trashcan to delete it [21:25] that makes sense [21:25] trashcan I think is supposed to be all the way through, not just on Settings inspector panel [21:25] do you have a link for the latest wireframe? [21:25] mine is v1 it says [21:26] hatch look in email from luca...or short answer is https://drive.google.com/a/canonical.com/?tab=co#folders/0B7XG_QBXNwY1V3B3dDNvYXJGRE0 :-) [21:26] oh I don't think I got that email [21:27] i've never seen this page before :) [21:27] * hatch wants to * folders [21:27] oh goodness, that wasn't sent peeps [21:29] hehe woops [21:29] forwarded [21:29] anyway hatch, the trashcan disappeared [21:29] alright I'll pretend there is one there [21:29] hatch, +1 thanks. I'll ask luca [21:53] bcsaller: would you be ok with putting the 'factory' in environment.js along with the get/setInspector methods [21:53] hatch: I can get back to you in a few minutes [21:53] no prob [22:06] I like being able to leave multiple panels open with the simulator running and watching the units come and go. [22:15] Morning [22:30] bcsaller: some light watching the sunset....you're weird [22:30] :P [22:30] lol I actually enjoy watching the simulator too haha [22:31] it shows how far we've come with the update model [22:35] yeah the dispatch issue is allllllmost gone :) [23:01] bcsaller: should this.get('db').charms.getById(model.get('charm')) work where the charm attribute is precise/ceph-11 [23:01] it returns null [23:01] which isn't possible as far as I can tell because it's already been loaded [23:03] not cs:precise/ceph-11? [23:05] no, that looks right [23:05] yeah actually the charms modellist is empty... [23:06] I was just about to ask that [23:06] app.db.charms.map(function(m) {return m.getAttrs();}) should have looked sane [23:06] so we have a bigger issue here then [23:06] that service shouldn't hit the env without a charm in the db [23:07] hatch: is this the drag/drop stuff? [23:07] it previously jumped through hoops to get the charm loaded, sounds like its not anymore [23:07] * rick_h is just joining into irc after a while away [23:07] rick_h: nope using 'add' [23:07] hatch: k, so that should pass a ready model instance into the deploy command [23:07] ahh ok we never add that into the db [23:07] hatch: we create a full model from the object we pulled form the Browser api [23:09] rick_h: do you pull down the full charm data all the time or only when I click add ? [23:09] hatch: so when you hit add, we've already gotten all of the charm data from the browser code. in subapp/browser/views/charm.js there's the _addCharmEnvironment that's walking that through [23:10] there's no point pulling data from the old api, we just convert an instance of BrowserCharm to Charm and send it along. [23:10] *sigh* umm ok [23:10] I knew this would bite us eventually haha [23:10] hatch: so this.charmPanel.deploy is the method that's called with the model instance [23:11] right right [23:11] where this is the main App [23:11] `this` [23:11] that data should be pushed into the db [23:11] then on subsiquent requests we don't need to query the api [23:11] and also have it available when we need it hehe [23:12] I'm not blaming or anything just outlining what should probably be done moving forward [23:12] holy it's past 5 already [23:12] rick_h: is what I mentioned possible? [23:12] possible with minimal work that is :) [23:16] hatch: sorry, at a coffee shop and in/out network [23:16] hatch: so yea, it's probably possible. benji did the initial add functionality and we can get the model into the db just fine. [23:17] hatch: I'd suggest the charmPanel.deploy method do that when it get a s model [23:18] that's what I was thinking [23:18] rick_h: I remember us talking about needing to use a single charm model down the road [23:19] I think we are down the road :D [23:19] hatch: yea, ideally we'd ditch the old Charm model and just use BrowserCharm [23:19] hatch: I've got a card I want to do to audit all the calls to the old api and deprecate/get rid of them [23:19] once that's done the model switch should be easy [23:19] hatch, rick_h : I haven't thought through all the implications of what your saying but remember wrt charm loading that the GUI isn't the only source of these, the delta can bring in new services that may have charms not even in the store, so the existing code paths maybe still needed [23:20] bcsaller: definitely, but ideally we could shim them into a BrowserCharm instance and get to combine them bit by bit [23:20] bcsaller: but yea, I've not chased it all the way through. However we had the vision of loading environment charms into the browser as well so we need to get to one 'model' for it [23:21] it's just not been priority since we pulled it from the 13.04 browser goals. [23:21] I'm fine with the idea that the browser is the source of truth for charms in the client. [23:21] bcsaller: right, the API from manage.jujucharms.com needs to be the single point of data for things vs the old jujucharm/search/json and search. [23:22] my issue is that if you close the inspector for a ghost and need to create a new one, the charm data no longer exists anywhere [23:23] so pushing it into the db will help that case [23:23] the case where it won't help however is when we open the page [23:23] hatch: can we sit down and chat tomorrow about it? [23:23] yeah it's past my EOD anyway I suppose heh [23:23] hatch: ok. Let's try to at least build a checklist of stuff to make sure we sanity check/run through and go from there. [23:23] build a todo list for getting it 100% straightened out [23:24] good idea [23:24] I don't really like how this is working anyways [23:24] hah [23:24] the code I'm writing [23:24] I mean [23:27] didn't we talk about having fully populated service with charms at all times? [23:27] so if you loaded up an environment with X services on it, the service and charm models would be ready to go [23:27] did that go away with deploying from the charmstore? [23:27] s/charmstore/browser [23:28] hatch: so the charms are always fully loaded. When you browse, we have all the charm data so that we can pass it to the env or config panels or anything without making a new http request. [23:29] hatch: we keep a cache in the browser subapp, but we might need ot hook some of that up to the db or other place in the env. I'm not sure tbh [23:29] I've not looked through all the other uses of the base charm model. [23:29] I mean if I load up an environment with a set of services already [23:29] those should be populated with charms no? [23:30] or did we decide to leave them as shells [23:30] yes, but using the old apis and whatever the juju environment feeds out of the websocket connection [23:30] e.g. that's not changed at all [23:31] right ok - so in theory we could change the browser cache to use the charm db [23:31] but anyway, it's 7:30pm and I'm trying to hold multiple conversatoins at hte coffee shop. Can walk through this tomorrow. :) [23:31] haha yeah sure np [23:31] have a good night [23:31] you too