[00:00] ahh - yeah one model might be cool - but I'm guessing that there is enough difference that keeping them separate is probably a good idea [00:00] I have no data/experience to back up that claim however ;) [00:00] hatch: right, but one modellist, container can take either, token can take either, etc [00:01] there's two models, but a LOT of code that we want to be able to use either. Showing a readme is the same either way [00:01] right [00:01] thats all shared [00:01] yea, all good, carry on. Will look forward to poking at it tomorrow [00:01] https://code.launchpad.net/~hatch/juju-gui/bundle-detail-tabs [00:01] there is the functional branch without qa/tests [00:02] but the current tests/basic qa all pass [00:03] why can they not share the tabview setup vs having it in bundle.js and charm.js? [00:05] because....I didn't think of that [00:05] SO THERE!! [00:05] ok, you gave me the link. I'll wait until tomorrow :) [00:05] lol [00:05] no it's cool thanks [00:05] I'll do that [00:06] and while you're in there, we should setup a common attr vs the whole storeId vs entityId thing. [00:06] that's fugly [00:07] other than that, initial look is good :) [00:07] yeah I was thinking the same [00:08] ok tabview is moved....id thing will have to wait [00:08] off to make supper [00:08] cyaz [00:08] enjoy! [01:20] bcsaller, hey. was trying to figure out why deploying wasn't working so well, and hacked around and came to http://paste.ubuntu.com/6207496/ . Realized toward the end that I had encountered, at least in part, some of the same things you had mentioned. My sandbox hack does not handle pyJuju, for instance, which was the kind of thing you mentioned today on the standup. I found a few other things though, as you'll [01:20] see. Maybe we can compare notes tomorrow. Meanwhile, running off. :-) see you === _mup__ is now known as _mup_ [11:19] gary_poster: around? [12:04] rick_h_, am now, but about to go vite [12:04] vote [12:04] gary_poster: all good, have fun [12:04] cool will ping when I return [12:14] luca__: ping, got a sec? [12:20] rick_h_, here [12:20] gary_poster: that was fast [12:20] rick_h_, I vote like the wind! [12:20] or something [12:21] gary_poster: k, quick hangout then? I wanted to clear up yesterday so I'm on the right track for today [12:21] rick_h_, cool. https://plus.google.com/hangouts/_/f2514e8843a5c2c1877fda92051ec0612813c92f [12:26] gary_poster: and reviewed huw's branch, small issues we need to clear with ux. screenshots included. https://codereview.appspot.com/14526043/ [12:27] gary_poster: so that's going to hang for a bit [12:27] but did review it [12:29] rick_h_, ok cool thanks. It looks right to me--the top border is a 3d highlight to my eye, so I don't expect the triangle to go "in" the crevice--but yeah, good to check with luca__ [12:31] oh rick_h_, can you do the three-line switch from jc: to bundle: if you have not already? [12:31] gary_poster: yes, will do. [12:31] thank you [12:38] rick_h_, maybe interesting thought and maybe you've thought about already: if new icon paths redirect from various general paths to a *version-specific* icon path, then we can set the icon's version-specific path to cache headers of "forever" [12:40] gary_poster: well, the issue is we support 'latest' (revisionless) ids and that would cause us issues [12:40] rick_h_, but if the revisionless ones are redirects as well.. [12:40] gary_poster: I'll double check/look. [12:40] cool [13:02] abentley: what time does sinzui normally get in? [13:03] benji: He's usually around by now. [13:03] benji: He's just not on this channel. [13:03] ah, thanks === TheRealMue is now known as TheMue [13:56] rick_h_: heya [13:56] rick_h_: it looks off [13:56] luca__: yea, I thought so [13:57] luca__: none of hte visuals go over the triangle I can see. They're all still stars [13:57] luca__: I think it's because we had kind of a beveled divider between charms [13:57] rick_h_: yeah [13:59] rick_h_: ok, so after showing Spencer [13:59] rick_h_: he says that the triangle on the charm token should line up to the dark line [13:59] rick_h_: not the highlight [14:00] rick_h_: and the triangle on the bundle details should be bigger at 20px x 20px [14:00] luca__: ok, can you guys reply to the email for Huw to look to update the branch for tomorrow then? [14:00] rick_h_: sure, will he need a bigger triangle asset for the bundle details? [14:00] luca__: let me look [14:03] luca__: I'm not sure on the size. If you guys have one to include inthe email that'd be great. [14:04] ok [14:04] luca__: thanks for looking at it. Let me know if you've got any thoughts on #2 in that email as well even if it's just a 'Nope, nothing right now' so I can answer the question when/if it comes up please. [14:05] rick_h_: I think improving search should be something we discuss in SF [14:05] luca__: rgr [14:05] rick_h_: we need to look at it with all the new things we've got and the future features [14:05] rick_h_: I'll get Ale to set up a meeting :) [14:05] luca__: ok cool. Good enough for me. [14:05] * rick_h_ runs away [14:06] rick_h_: haha [14:09] rick_h_: why not use css for the triangle? [14:10] hatch: no idea. I've not done enough triangle css to suggest it or know if it would fall over here. [14:10] hatch: trying to keep involvement to a review :P [14:10] cool. the gui charm with a local release takes 50 secs on ec2 from the install hook invocation to deployed [14:10] hatch: btw, since you're online now. I saw the new YUI, but notes include changes to route/app and such so between us let's make sure we watch out for it [14:11] frankban: woot [14:11] rick_h_: ugh yeah - I don't agree with that change but whatever [14:11] hatch: yea, the req object has some diff bits as well. Enough that I went "whoa, we'll have to update for this one" [14:13] yeah I don't get the idea behind the update besides being different [14:13] I don't see where the old techniques fell down [14:16] LXC really is awesome [14:16] benji: +1 [14:23] gary_poster: hatch so for this story of "I drag a bundle file onto the gui and need charm icons to show up" story we were talking about an api call that supplied the icon via the info in the bundle. [14:23] gary_poster: hatch but I'm wondering if we need the full charm data itself as well? For the rest of things to work? Or is that not necessary? [14:23] the bundle contains the deployment data [14:23] so it's just the images that are required [14:23] hatch: ok, so there's nothing else in the UX besides the icon that we need from the charm that's not in the deployment data? [14:24] hatch: ok cool, sounds like a plan to me then. [14:24] rick_h_: I was thinking that when we create the models for the services the model should check if it has the required data and go fetch it itself [14:24] rick_h_, on call [14:25] hatch: right, just wanting to think this through once vs redoing it. If we'll need some extra data for all the charms does a single enpoint make sense? Are we going to call out once for every charm in a bnudle, etc? [14:26] it would be nice if the endpoint would take a series of id's [14:27] and return the paths for all of htem [14:27] hatch: well it's going to return the actual icon. So you'll just have

[14:27] but I was worried about other data [14:28] ohh ok I see, so the model still won't have the image path [14:28] hatch: yea, it builds it currently. [14:28] hte model never has the image path tbh [14:29] oh I suppose [14:29] well I guess it 'should' cache the image using this approach [14:29] don't know why it doesn't cache them here though :/ [14:29] hatch: definitely, it's how it works now [14:29] hatch: yea, you're broken. [14:31] I must have an extension somewhere which is causing it to break or something [14:31] ugh 700ms OPTIONS requests.....we gota fix that lol [14:31] hatch: yea, or just turned off caching in the chome dev tools [14:32] hatch: refresh a few times [14:32] hatch: that should ONLY happen on the first one in a series after chrome closes the connection upstream [14:32] lol that's not a real sollution [14:32] hatch: well it is in normal use. You take a hit on first load and then it's fast [14:35] hmm the waterflow sure seems to indicate a server issue [14:35] but ooookkkkkk [14:39] hatch: :P [14:48] has anyone else done that 'javascript under pressure' ? it's pretty cool :) [14:49] should be used when hiring js devs haha [14:56] oh rick_h_ last night I finally got the colours all sorted out - had to drop zsh as it somehow conflicted with vim and the terminal colours [15:11] I just had an expecially geeky moment. Instead of getting up and going to look in a mirror I turned on my webcam. [15:12] benji: never thoght of that! [15:12] thought...man I can't type today [15:12] laptop keyboard gah [15:13] I like my laptop keyboard so much [15:13] I bought an external one [15:13] (doesn't keep me from pressing enter too soon though) [15:13] well with the more powerful desktop spending a LOT more time on it and the clicky larger keyboard [15:13] * benji adopts the e.e.cummings IRC technique. [15:14] yeah, if I could get a narrow model M with a good trackpoint I would be in keyboard heaven [15:14] meh, one day I hope the patent stuff in the three button trackpoint ends so others can steal it [15:15] and unicomp needs a 10less model so so bad [15:16] I have seriously considered custom building a keyboard, but I need another project like I need a hole in the head. [15:17] heh buttons...you silly people without multitouch gesture support [15:18] benji did you hear back from kentb? [15:18] gary_poster: yeah, he should be attempting the install nowish [15:18] great benji [15:20] gary_poster: I'm presently wrestling with importing the charms; I have a charm ingested now, but it lacks all personality (no icon, readme, description, etc.) because the charm isn't in the charm store; working that out now [15:20] cool benji, thx & good luck :-) [15:20] "we're all counting on you" [15:23] may the ice cream be with you [15:24] lol [15:24] * hatch hopes its soy based [15:50] jujugui call in 10 [15:50] Mr Kotter! [15:50] ugh... [15:50] foiled again [15:52] Hahah, has no one set up a calendar bot yet? :) [15:55] jujugui looking for a review/qa plz https://codereview.appspot.com/14531046 [15:55] hatch: happy to but will be a little bit [15:55] like 5 minutes? [15:55] or 5 hours? [15:55] :P [15:55] hatch: like before EOD, but probably not for 1-2hrs [15:56] ohh I want to keep moving on this stuff so someone else pick it up :) [15:57] I'll get it. [15:57] thanks [15:58] jujugui call in 2. hatch, you doing the honors? [15:58] yup [16:03] If I skipped out, nothing to say on my card. [16:03] The two in upgrade charm are down to 6 failing tests. [16:15] gary_poster: any specific bundle card you want me on? Or just pick one from the details page? [16:16] guihelp: does anyone know what charm revision is running jujucharms.com? [16:16] frankban: my guess would be the charmers one [16:17] revno 76 I think [16:17] frankban, yes, I think most recent [16:17] * hatch would loooove a charm update though ;) [16:18] hatch, charm icons or source tab [16:18] gary_poster, hatch: cool thanks, I'll use that when trying the charm upgrade steps [16:18] hatch, I had hacked on charn icons but I should not do it. I could share thoughts/code if you were interested though [16:18] alright I think I need my current branch to land for source tab so I'll do the charm icons [16:18] makes sense frankban [16:19] oh ok - yeah if you have a branch [16:19] I haven't looked at all at it [16:21] hatch, http://paste.ubuntu.com/6209987/ and https://plus.google.com/hangouts/_/10fe9c48d75b9ebbe273219cb03f4e53869ce4f7 ? [16:33] thank you for webops work rick_h_ . sounds like you're on the track of it. awesome, and sorry for the interruption. [16:34] gary_poster: all good, sorry I'm out of date on how the stuff works floundering around so much. and thanks abentley for helping peek at it as well [16:36] rick_h_: you're welcome. [16:36] rick_h_: FWIW, I have no clue what's going wrong with the branches. The proofing happens at a later stage, so the branches should already be checked out by then. [16:37] abentley: yea, well we copied over the branches [16:37] so they exist on disk now [16:37] abentley: originally when the data was copied without the branches ingest came behind and make all the config bits empty, emptied the summary, etc [16:38] abentley: so the branches are there copied from the old server and guessing it's trying to proof and it's got a -60 rev version of proof tools missing bits needed? [16:38] rick_h_: Right, so we still don't know why we couldn't copy them. [16:39] abentley: right, that's still a bug in the deploy for sure. [16:39] it should have recreated them if it didn't have them on disk [16:40] I guess we can test that locally by doing a dump from staging. === abentley is now known as abentley-lunch [16:41] hatch: comments sent, but didn't qa or go over 100% since I'm just drive by inputting :P [16:41] hatch: thanks for the updates though! [16:42] jujugui ill, need to lay down, can someone else grab frankban's second review? https://codereview.appspot.com/14545044 [16:42] * gary_poster already reviewing it [16:42] I was #2 [16:43] Will try to get to it later if I don't in a bit [16:43] That didn't make sense. [16:43] Whtever, back i na bit [16:44] feel better [16:50] rick_h_: thanks will look [16:51] man you really hate attributes hey? lol changing [16:51] hatch: well <3 them when you need them. They're awesome and magical. [16:51] hatch: but this is not a case of needing them [16:52] I really wish someone would write a native js object attribute shim [16:52] which could 'upgrade' when necessary [17:08] rick_h_: so I have changed it to be a static but I"m not sure it should be done like that [17:08] we now have to go instance.constructor.entityType to access it [17:08] which is not discoverable really [17:09] for those not in-the-know [17:10] Ugh, okay, sorry. Will do that review if no one else picked it up. [17:14] Makyo: you were only down for 15 mins :) [17:15] hatch, I'd rather be working :P [17:16] haha - I've been 'off' for about a week, I'm chalking it up to the weather [17:16] fall alergies and whatnot [17:16] Yeah, lots of that going around. [17:17] Lost my appetite, and Makyos cannot subsist on espresso alone, apparently, nice as that'd be :P [17:22] you probably could on espresso and sugar [17:22] at least for a few weeks [17:22] then you'd probably die though [17:22] I can't imagine my kidneys would be very happy :) [17:22] Hahaha [17:31] gary_poster: status update: kentb has a working gui with stock charms, I have a gui with (mostly correct) ice cream charms [17:59] benji, yay! [18:04] quit...writing...tests...with...actual, expected...switched...around [18:04] problem is that different frameworks have different orders, IIRC [18:05] yea, I'm back on python side and it's switched [18:05] and I keep writing ; and this. [18:05] gah! [18:05] yep, and Python has done the only sensible thing, stopped prescribing an order [18:06] if you don't prescribe an order then you don't know which is correct [18:07] the output should put them in the order give to it [18:07] at least then it would match the code [18:07] it's all this "words are better, let's write out full sentences and try to use english to explain your failure" crap :P [18:07] lol [18:07] test_something failed: [18:07] 1 != 2 [18:07] all I want [18:07] with a line # :) [18:08] that would be fine with me! [18:09] right now I have to actually investigate every variable to figure out what is what [18:09] you can debugger; tests [18:09] and then just use chrome to look at all vars in scope [18:09] or firebug, or whatever [18:09] another step [18:09] yea, but better than " investigate every variable" [18:09] that's what you just said to do lol [18:10] hatch: gary_poster so this is setup that if we can't find the charm we just respond with the generic charm icon. I don't know why we'd 404, but the through crossed my mind so sharing my assumption [18:10] rick_h_, +1 [18:11] if we can't find it then how do we deploy it? [18:11] he's talking about icon [18:11] yea, sorry. Get into my mental context darn it :P [18:11] ohh ok then yeah that's fine with me [18:11] :) [18:12] rick_h_, actually better: *redirect* to unchanging location of generic charm icon [18:12] rick_h_, better for cacheing [18:12] caching [18:12] agree? [18:12] gary_poster: yea, all of this is a redirect [18:12] well it would have to be a 'temporary redirect' [18:12] so not sure if that would help cache anything [18:12] hatch it would cache the end result [18:12] abentley-lunch: pointed that out to me. Even if found it redirects to the right icon under the right ID in the hopes you might already have that cached [18:13] excellent === abentley-lunch is now known as abentley [18:13] oh right - but it'll still make the request [18:13] can you set an expires on a temporary redirect? [18:14] hatch yes will still make a request, but still much cheaper than actually downloading the svg over and over again [18:14] true dat! [18:14] I don't know anything about cacheing a redirect. interesting question [18:14] although we spend way more time connecting than downloading with our server for some reason [18:14] caching! :-/ [18:15] to the googles! [18:15] gary_poster: they do cache redirects [18:15] http://stackoverflow.com/questions/691877/why-does-the-browser-not-cache-a-301-within-an-ajax-request/691949#691949 [18:15] <_mup_> Bug #691949: Misleading description of language-pack-de

[18:15] browsers respect cache headers on redirects [18:16] cool so we could add that as well to speed things up a bit [18:16] apparently as of 2010 not so much but nowadays it is AOK [18:16] yeah [18:17] http://www.browserscope.org/?category=network [18:17] according to that we are good to go [18:18] I'm doing the test on my own browser now for amusement sake [18:18] cool [18:18] ok back to writing tests.....*grumble grumble grumble* [18:18] :-) [18:19] ugh apple broke itunes podcasts section again.... [18:19] man today is just not a good day [18:43] man I <3 python [18:55] me too [18:55] * benji and rick_h_ join hands and Kumbaya. [19:01] bah, hate it when tests out in no where fail. "But but but...I didn't touch that code!" [19:14] benji: have a sec to review https://code.launchpad.net/~rharding/charmworld/bundle-icons/+merge/189942 ? and can you qa/make test and verify you also get a test failure on the misc test for the homeview? [19:15] benji: I can't see wtf I did to change that and wondering if it's something local. [19:16] man, trunk passes...I must have done something. [19:21] die spurious test failures die [19:22] gary_poster: I just sent Kent an updated setup with the ice cream charms after going through the full install myself [19:22] awesome, benji! [19:22] benji, did you see my reply to Mark Baker? [19:23] benji, and his reply [19:23] the export to a nfs shared mount seemed doable, yeah? [19:23] gary_poster: I say your message, but I don't think I saw his [19:23] s/shared// :-) [19:24] benji, pertinent bit was "maybe just save the yaml file to a shared drive even. " [19:24] (he did send it to me alone, it seems) [19:24] gary_poster: i.e. the export mechanism? [19:24] benji right [19:24] I don't see why it wouldn't work, but I haven't tried it; I'll try now [19:25] rick_h_: May I use your landing as a guinnea pig for testing whether team-based permissions are working? I thought they were broken, but that may have been a bug in the charm. [19:25] benji cool thanks [19:26] abentley: sure thing if I can get this stupid test to pass [19:27] abentley: benji any experience with using enable_routes causing straing behaviour? [19:28] rick_h_: Nothing comes to mind. [19:29] benji: doing a stupid stupid thing in this to move forward. Please avert your eyes and I'll file a bug [19:33] jujugui or anyone else up for a charmworld review? https://code.launchpad.net/~rharding/charmworld/bundle-icons/+merge/189942 [19:33] will look soon if no takers [19:40] cfvdtrbkktfvcinvjufbucbinibirinnb [19:40] ccccccbgjgvcfiujgetvtenddglclldgrgldtelejbvk [19:40] bah [19:42] lol [19:43] mine is in the side of my monitor so I can't hit it haha [19:43] or if I did....it was one heck of a party [19:51] rick_h_: lol awesome merge description [20:00] gary_poster: the export works with the ice cream setup; my Chromium automatically saves the export in a directory and appends incrementing numbers to subsequent downloads, so theoretically someone could also access that directory and look at timestamps or be given the parenthetical number (which is displayed by chrome) [20:00] ok, I have to go to my appointment now, back in about an hour [20:01] benji great! will pass it on, thanks [20:30] ugh this test is infuriating [20:53] * benji is back. [20:53] jujugui small branch for review by one. https://codereview.appspot.com/14565044/ [20:54] I'll do it [20:54] hey benji [20:54] * hatch needs abreak [20:54] thanks hatch [20:54] benji, you going to look at rick's charmworld branch, or shall I? I can look at code but am not yet set up for QA. If you do QA, could you verify that the svg he is using is the gray one, not the black one? [20:55] gary_poster: I'm working on an issue Kent is having (he isn't seeing the icons) [20:55] benji ok cool, I'll take it. thx [20:56] * gary_poster was about to take break when he realized it was about to be EoD :-P [20:58] gary_poster: I've got the black one in there. Updating with the grey one now. [20:58] cool thanks rick_h_ [20:59] updated to use https://docs.google.com/a/canonical.com/file/d/0B9WMKNMU_KombXJYUmt5OWJRY2c/edit?usp=drive_web and pushed up [20:59] thanks for the reminder [21:00] rick_h_, did you have tests for the bundle icon thing? I'm sorely tempted to have you add it back in so we don't lose the work. wdyt? [21:00] (assuming that adding it back in means reverting a revision) [21:01] not sure what the 'bundle icon thing' is? I added the icon, added the work to return it from charmworld, and did the charm icons via new api endpoints in there [21:01] I didn't revert anything or go back. It was already done when we talked so just kep going forward [21:01] gary_poster: I did not and had not gotten to serving out the icon.svg in the bundle if it was promulgated so that's just not complete [21:01] but per our call we don't want that to occur right now [21:01] rick_h_, oh ok cool. that's what I meant. nm then, yeah [21:02] rick_h_, you "# See if we have a /series/name." should we also include logic for ~user/series/name? that's a question, not a request, to be clear. [21:03] gary_poster: I didn't see that supported. If it uses the name it's only because it's a promugated charm. Let me pull back up the deployer file [21:03] gary_poster: done with trivial [21:03] hatch awesome thank you [21:04] rick_h_, ah promulgated. Maybe add a comment about that. [21:04] gary_poster: rgr [21:05] gary_poster: so the logic I followed for all of this was http://bazaar.launchpad.net/~juju-deployers/juju-deployer/trunk/view/head:/deployer/charm.py#L43 from the deployer [21:06] gary_poster: so it's only checking the branch and charm keys in the service section of the deployer file if I read that right [21:06] gary_poster: no owner/etc [21:07] ack, looking [21:08] bah, looks like I did transfer that wrong. There's a charm_url, charm, and branch. Missing charm_url. wonder what that is. [21:08] well, not wrong, but incomplete [21:09] looks like it is another cs:, rick_h_ [21:09] that was my assumption, but...assumption :-) [21:09] gary_poster: I think it's for local? http://bazaar.launchpad.net/~juju-deployers/juju-deployer/trunk/view/head:/deployer/charm.py#L75 [21:09] in which case we'd just not find the charm anyway. [21:10] yeah [21:10] though I don't even know what d is in this context [21:10] but anyway, that's the general idea is to support the data that deployer function does. [21:10] and don't want to dig to find out this second [21:10] gotcha. comment to that effect sounds sufficient [21:10] d in this context is the service dict from the data.services section of the deployer file [21:11] rick_h_, as further populated by that other code you mentioned? [21:11] http://bazaar.launchpad.net/~juju-deployers/juju-deployer/trunk/view/head:/deployer/charm.py#L75 [21:12] gary_poster: yea, I'm assuming that the d charm_url is the same one it would generate from the object here. [21:12] gotcha [21:12] gary_poster: the result of this parsing is then passed back to Charm.__init__() [21:12] gary_poster: the result of this 'from_service' call [21:14] rick_h_, code LGTM. I'd love to see test verification that the end result url has a version in it, but I'm guessing we already have similar tests of API3._get_api_id. Wuld also be nice to have tests of cache headers, but I doubt we're generating them. maybe file bug? [21:14] Meanwhile I have not qad. Doing so will take me awhile, since I have never built charmworld. do you need me to? [21:14] Or is code LGTM sufficient? [21:15] gary_poster: I think a LGTM will be good. We'll hit staging first. We can it against the data there. and maybe even get to QA it with Gui changes before it goes to production [21:16] and right, the version info is based on the lp branch of cs: urls passed in. I've got other tests that verify that the right charms are found/built [21:17] you're right I didn't make sure there are cache headers on this calls, but because they're not versioned, the ones to cache are the redirected icon urls [21:17] they're so fluid ugh, but it's what the deployer does [21:18] right [21:18] Approval is in there [21:18] thank you! [21:32] hatch, before your EoD today, could you ask huwshimi to style what you've landed today--details view & readme I think? [21:32] once I get it landed :/ [21:32] heh [21:32] I've been fighting for hours writing the tests [21:32] ok [21:32] :-( [21:33] either the promise or the assertion captures the failures [21:33] hatch: is this something you'd like to talk through? [21:33] so it's very difficult to debug [21:33] bcsaller: nah I'm on the home stretch now, thanks though [21:59] gary_poster: did you ever reply about my comment? [22:00] sorry I was actually curious as to what the resulting difference was :) [22:02] bcsaller: so I"m all done now - but I was curious if you had a technique to avoid the assertion failures being captured by the promises [22:03] hatch: usually after the final call you can add .then(undefined, done) to the chain [22:03] that's only if the call returns a promise [22:03] thought of that ;) [22:04] Morning [22:04] your test didn't happen in the .then of a promise return? [22:05]