[00:00] I'd just hate for you to go down the wrong hole [00:53] got it :) now to make it all actually work out [00:54] nice [00:54] got a diff? [00:55] oh, on gh [00:55] :) [00:55] https://github.com/juju/juju-gui/pull/254/files [00:55] yea [00:55] working through it, I know I just blew up a TON of tests [00:55] so let that roll and generate a big giant number for mw [00:55] for me that is [00:56] ✖ 27 of 1694 tests failed: [00:56] not bad actually [00:56] ahh you moved the search view out of the sidebar [00:56] nice [00:56] good move [00:56] right, we're working around the sidebar having the single search UI stuff [00:57] so this kicks the workaround and just makes it work *right* [00:57] yup good call [00:57] then the card fix is the one line ✖ 27 of 1694 tests failed: [00:57] viewCfg.filters.text = metadata.search; [00:57] that line ^ [00:57] is the actual card issue [00:57] yep [00:58] much nicer without all of the workarounds to keep it in the sidebar [00:58] right [00:58] and seems to work ok here in a quick dev/test run of it [00:58] makes the home button work out fine, etc [00:58] sidebar is doing less and less :) pretty soon it'll just be a div haha [00:58] hey, I always said it should be [00:59] just a single container to style and clear/etc [00:59] anyway, now on to problem two for the night [01:00] good so looks like you fixed that the proper way so I'm happy [01:00] I try to do things right :) [01:00] lol, I mean, instead of introducing another workaround [01:01] so does the state workflow make sense now? [01:01] yea, little bit. The "it ONLY goes through routeDefault" was really easy to miss [01:02] it'll need some comments and some others to grok it and it'll be cool [01:02] we had talked about it in principle, but I'd missed the actually talking to code [01:02] and it calling the same sidebar() threw me as it does a ton of work that clearly wasn't meant to be done in the routeDefault [01:03] ahh yes yes, there is going to be so much code that will be removed [01:03] I'm sure it'll be sad to see all that code you wrote go away :) [01:03] not at all [01:03] this is stuff I always knew/hoped would get cleaned up [01:03] it's not like fullscreen where I STILL think it's the only decent way to search charms/bundles [01:04] oh bah bah bah, stupid breakout panels [01:04] lol - yeah they will add it back in [01:04] I know it [01:04] no, it's going into the new project so not our problem [01:05] ohh gotcha [01:05] but it will be a fullscreen experience, so at least I can feel like I was right [01:05] sounds good [01:05] haha [01:05] :P [01:06] well I'm going to pop off, see some of you in DEN, the others in LAS [01:06] have a good night [01:06] have a good night and safe travels [01:06] thanks you too [01:12] hatch: See you in a few days! [01:15] huwshimi: make sure to block out thurs during sprints for hte team dinner [01:16] rick_h_: Sure thing. [12:03] * frankban lunches [12:29] rick_h_: my parents dropped in to stay with us last night. i can come to the call at 9 but i may have to hop off in the middle for a few moments to see them off. [12:30] jcsackett: all good thanks for the heads up [12:30] jcsackett: I can run through it early/later if it works better [12:30] just wanted to get the word out [12:30] how long a call do you figure? [12:30] 20min? [12:31] you want to push it to 9:30? they claim they'll be gone then, so no interruptions. :p [12:31] jcsackett: ok, will see if kadams can [12:31] ok [12:40] rick_h_: update on charmworld deploy. it has been bumpy due to obsolete bundles on production that never got updated. data on the new staging was fresh as it came from ingest with current proof rules. some bundles on production do not pass proof rules so it took a few iterations to get the migration right. [12:41] rick_h_: thedac worked out the procedure to copy the prod database to staging and the latest code drop did the exodus cleanly. so now we just have to apply it to production. waiting on him to handle it so i don't have to bring the vanguard up to speed. he's vancouver-based so it'll be a few hours. [12:43] bac: since bundles are one revision and reimportable can we blow them away and then migrate? [12:44] bac: do we have the code in place to convert the strings on reingest? [12:44] rick_h_: as i said, the exodus works cleanly now on a copy of the production db. so it should apply to production ok. i'd rather let it run when thedac gets in. [12:45] bac: sorry, read that as it applies on a clean db [12:45] rick_h_: yes, ingest does the convert [12:45] bac: ok cool [12:45] bac: thanks for the heads up. Let me know what we need in case you need to head out before things complete [12:46] ok. RT 69701 (noted in card) has the details [12:50] morning all [12:50] ugh. just realized i have to pack for cold/rainy and hot/dry. [12:50] hi hatch [12:51] bac cold/rainy? Where are you going? [12:51] bac: heh, I hate that. [12:51] packing for montreal sucked, but looking forward to just vegas [12:51] flight delayed 3h, sitting at airport....awww yeah [12:52] lol [12:52] * hatch puts on sunglasses like CSI [12:52] free wifi at the airport though [12:52] slow....so hotspotting instead [12:53] hotspots always seem better than airport wifi. [12:53] LTE hotspot will definitely be better than airport wifi lol [12:54] and I don't have to worry about anyone wiresharking me [12:54] haha [12:58] rick_h_: i'm guessing 9 is still go time, which works for me. [12:58] jcsackett: ok [12:58] jcsackett: yea, not seen kadams yet this morning [12:59] rick_h_: yeah. i'm guessing his hours start at 9 like mine, but he has less of an email addiction. :P [12:59] heh, he accepted late last night :P [12:59] and kids [12:59] :) [12:59] i take it all back. we'll just blame the kids. [12:59] :p [12:59] +1 [13:00] our new airport has plugins at each seat.....everyone here is on a laptop [13:01] rick_h_: i think, given you assigned me to a card i thought i was already assigned to, that i wasn't connected to the internet when i was manipulating kanban yesterday evening. and now i find that to move my card goes over lane limits. should i do so? don't think we have time for me to do slack while waiting. [13:02] jcsackett: over limit is ok. we'll clear it out today and priority is prepping for release [13:02] jcsackett: if you were really motivated you could review/land huw's branch to make room [13:02] but I can try to look at that after our call [13:03] if you don't have time for that i can certainly review it, but also post call for me. [13:03] but Makyo's card should be landing, it was in review and commented on yesterday [13:03] rick_h_ http://www.engadget.com/2014/04/22/air-berlin-pebble/?ncid=rss_truncated :-) [13:03] hatch: nice [13:03] thought you'd like that....being a pebble user and all [13:04] the ios part sucks but oh well :P [13:06] haha yeah [13:15] hatch: heh you wanted deleting https://github.com/juju/juju-gui/pull/255/files [13:15] noice!! almost 1k lines [13:15] where we're going, we don't need code! === BradCrittenden is now known as bac [13:30] jcsackett: if you're available let's do this sans kadams then. Not sure where he is [13:34] rick_h_: there he is, and i'm in the hangout. [13:34] jcsackett: in https://plus.google.com/hangouts/_/canonical.com/go-over-search?authuser=1 [13:34] rick_h_: it was attached to the appt, i'm already there. [13:34] jcsackett: try again, that's the one attached to the calendar [13:34] kadams54: and I are there [13:36] hey guys, did the gui stop showing icons for local deployments recently? [13:36] I moved a demo over to a new box and no icons [13:36] jcastro: no [13:37] jcastro: nothing changed recently, no releases done though hoping for one tomorrow [13:37] rick_h_, how can I force the icons on again? [13:38] jcastro: you can't at the moment [13:38] any idea why icons would show up on some machines but not others? [13:43] jcsackett, rick_h_: Google Hangouts is now crashing immediately on me… gonna restart the browser. [13:43] rick_h_, is there a bug for linking to the service's page from the gui? [13:43] services page? [13:44] so like I fire up say, hadoop [13:44] and I want to see the hadoop page [13:44] I have to URL mangle/guess [13:44] which hadoop page? [13:44] I need more info, we've got a lot of hadoop pages [13:44] I deploy hadoop in the gui [13:44] then I click on the box [13:44] ok, yes, you deployed it [13:44] then I find the unit [13:45] click, then I find the IP [13:45] then I click on it [13:45] but like, it takes me "x.x.x.x" and not "x.x.x.x:xxx/hadoop" or whatever it is supposed to be [13:45] ok, we don't know what hte url is in the charms [13:45] do they expose "available urls"? [13:45] right, I winder if that's a good idea [13:45] that's not something we can do. [13:45] like, it should be right, if you're in the gui [13:45] you should be able to hit any page on any service [13:46] ah ok, it's been talked about but we'd need the charms to expose it. I forget what it was talked about [13:46] rick_h_, I mean "we" as in all of juju, not just you [13:46] hmm, I'm going to ask [13:46] ok cool [13:46] yea, we can look at it [13:47] do any of you have time to help debug our gui? [13:47] we need the icons for mark's demo [13:47] jcastro: ok, otp give me 2 [13:47] Apparently the browser restart was not sufficient [13:48] kadams54: all good, I think we're set [13:48] Great [13:48] I shall go forth and code… er… test… er… fix broken tests… by coding. [13:48] kadams54: only question left was do i need to sync with your other branch, or just the one rick has put up? [13:48] kadams54: jcsackett let me know if you hit any issues that delay. We're squeezing in for release tomorrow [13:48] jcastro: sure thihng [13:48] jcsackett: my other branch is crap, so I suspect not :-) [13:48] kadams54: dig. :) [13:48] jcastro: is the gui up where I can hit it? [13:48] one sec [13:48] Too many rabbit holes with no results [13:49] rick_h_, do you have access to the lab? [13:49] jcastro: not that I'm aware of [14:41] rick_h_: hey, what would be the best way to take over your branch/PR? [14:41] I could use the `git qa-pr` alias to pull down a local copy… [14:42] kadams54: you could use the qa-pr tool to pull it down and wokr on it, rebase it, and then push to your own as git push origin xxx:xxx [14:42] (y) [14:45] jujugui did we ever figure out why mocha sometimes fails with no difference between actual and expected? [14:46] Makyo: because useless failure output is one of the mocha design goals? [14:46] frankban, +1000 [14:46] it is a wildly successful program, then [14:50] jujugui call in 10 [14:54] jcsackett: here are the logs from staging. https://pastebin.canonical.com/108999/plain/ [14:54] jcsackett: the beaker exceptions in app-exception.log have been seen for a while and thought to be innocuous [14:55] bac: the same errors are seen on production? [14:55] yes [14:56] huh. [14:56] that is a damn shame. [14:56] yeah, i don't see anything in here that explains the login behavior. [15:01] jcsackett: hangout time [15:01] frankban: ^ [15:01] Bah, Google Hangouts is crashing on me again… [15:11] So. assert.deepEqual(actual, expected) fails, but assert.equal(JSON.stringify(actual), JSON.stringify(result)) passes. Nice. [15:11] lol [15:15] I'm going to print this 100 times and ship it in a box to hatch's house http://hadihariri.com/2014/04/21/build-make-no-more/ :) [15:17] HAhaha [15:19] Once per day for a year? [15:20] that sounds good === BradCrittenden is now known as bac [15:43] rick_h_: charmworld updated and seems happy [15:45] bac: woot thanks! [15:45] bac: have a good trip, see you on the other side [16:02] * bac bye [16:10] jujugui ready for re-review - I've confirmed that the tests pass in IE10, but will be looking at the saucelabs video just to be sure. [16:12] rick_h_, icons still broken [16:12] and also it seems that when we deploy it forgets where the boxes are supposed to go in the bundle [16:15] jujugui forgot the link: https://github.com/juju/juju-gui/pull/253 (confirmed it was a timeout on saucelabs' side, too) [16:18] jcastro: k, bringing up a test environment [16:18] jcastro: will figure out how to build the url manually [16:19] Holy crap, they accepted our offer! [16:19] guihelp: I need two reviews for https://codereview.appspot.com/90570044 (quickstart/python, high priority) with my apologies for the long diff. Anyone available? Thanks! [16:22] Makyo: woot! party in vegas to celebrate! [16:22] jcastro: frankban can help look into it. Can you pm him the info from juju status and the environment admin secret so he can look at how to build a url to check if the files are in juju or not? [16:22] sure [16:33] https://www.flickr.com/photos/ranna/sets/72157644219100342/ 1.09 acres, 2362 sqft., hickory floors, quartz counters, glass backsplash tile... [16:36] go hickory, that's what I put in. <3 those floors [16:37] frankban: so if you're helping jcastro I'm going to go back to working on the inspector release blocker stuff. Let me know if you need a hand [16:37] rick_h_: sure thanks [16:59] rick_h_, all fixed, I owe frankban more beer [16:59] thanks! [16:59] :-) [16:59] jcastro: cool, what was it frankban ? [16:59] outdated charm branch [17:00] oh lol [17:00] nice and easy then cool [17:00] jujugui running out to pick up hatch from the airport. Will be back from the hotel. [17:01] Makyo: rgr, give him the grand tour and maybe find him some chicken and waffles :P [17:01] Hahaha [17:38] jujugui need a review and qa for a small branch please https://github.com/juju/juju-gui/pull/257 [18:48] kadams54: jcsackett either of you have a chance to review https://github.com/juju/juju-gui/pull/257 please? Tests pass now :0 [19:16] kadams54: jcsackett going afk. I'll be back tonight. If you need anything important ping me on hangouts [19:24] rick_h_: i may have time to look at it later today. [19:34] rick_h_: Taking a look… [20:05] rick_h_, can we make gui use the same trick it does for local charms on store charms? [20:05] rick_h_, re icons [20:06] rick_h_, ie. always get charm icons from the backend on deployed charms [20:14] guihelp /juju-gui ^ [20:58] hazmat: https://plus.google.com/hangouts/_/72cpi460salmu56blakp9rmtes?authuser=1&hl=en [21:00] hazmat: app/views/utils.js getCharmIconUrl has the if local condition you want [21:01] hi all [21:01] hey hatch [21:02] hazmat: testing it out on ec2 with https://github.com/mitechie/juju-gui/tree/always-store-icons [21:03] hazmat are you in DEN yet? [21:04] hatch: yea, he just ping'd from the hotel there. I think most folks are there based on earlier irc [21:04] oh cool, I got the sim card updated but had to pay the $10 for hotel wifi....ugh [21:04] charging for internet must be a North American hotel thing [21:05] yea, it sucks [21:05] was $25 when I was in chicago once [21:05] holy crap! [21:05] I think I'll hot spot for the rest of the time [21:05] man npm issues galore in CI [21:05] :/ [21:10] kadams54: did your branch land yet? [21:11] No, net yet [21:13] hatch: for you: https://github.com/juju/juju-gui/pull/257/files#r11924124 [21:13] ;-) [21:13] lol ^5 [21:13] * hatch ducks and covers [21:16] jujugui: can i get a review of https://github.com/juju/juju-gui/pull/258/files [21:16] kadams54: hatch what's the goal of the preventDefault vs halt? [21:16] rick_h_ halt stops the propagation of the event whereas preventDefault only prevents the default event for that handler [21:17] so you won't be able to listen on a container for that event and there will be no way to debug it [21:17] I view halt as a bit of a nuclear option [21:17] it burnt me hard earlier in the gui and in past projects [21:17] so I really try to avoid it [21:17] hatch: ok, but it's used on a close button. It's already on a container, and it's own html/template of control. No one else should be listening to that things events. [21:18] it's like having code across the page looking in case someone does some raw JS event on some temporary node used in a widget [21:18] you bind to events on the widget, not click events in the widgets html [21:18] otherwise it's fragile as can be [21:18] well say you wanted to capture all click events in a element for whatever reason [21:18] this click event would never reach your handler if halt is used [21:18] hatch: right, I'd scream to high heaven you can't do that :) [21:19] that's how pjax works [21:19] so no, I prefer my nuclear option in my widget :) [21:19] ok, will look at the scope but not sure this is an 'always good' rule and that it's appropriate here [21:20] the only reason halt is 'required' here is because of pjax, else prevent Default would work just fine [21:20] jcsackett I can review your branch [21:20] hatch: cool, thanks. [21:21] oh crud, I can't QA [21:21] I can't connect to my vagrant for whatever reason [21:22] probably this network [21:30] jcsackett done [21:30] you just need someone to qa [21:30] I can qa tonight at the coffee shop [21:30] hatch: how strongly do you feel about that personal preference noted? b/c it runs entirely counter to my personal preference. :p [21:30] rick_h_: thanks. [21:30] jcsackett haha, tbh I'll be voted down on it so up to you [21:31] I think it looks more like python style indentation [21:31] so I figured you python guys would prefer it [21:31] but doesn't look like it :) [21:31] hatch: multiple lines is per our code convention docs [21:31] on short constructs, yeah. on large blocks like that it makes it way harder to keep track of what's where, imo. [21:31] hatch: with any complex objects as their own var = line [21:31] hatch: we had a friday retro on this [21:32] jcsackett but in python you don't have that problem.... :) [21:32] we can revisit, but I'm with jcsackett. Seeing vars vs hiding vars. I hate we don't use the rule on out tests and don't force them to be alphabetical [21:32] rick_h_ yeah - I'm talking about the curlies [21:33] oh, that one [21:33] I think smushing all the curlies up on the end of the last line is cleaner [21:33] meh, I'm still with jcsackett. Lines up and easy to see. [21:33] the fact that you call it "smushing" is hurting your case :P [21:33] lol! [21:34] I don't ever think "boy that's some great smuching code. Much more readable smushed like that" [21:34] smushing [21:34] I really wish github had syntax highlighting in diffs [21:34] does anyone have that? [21:35] jcsackett I dont' think so, I think they all just colour the diffs [21:35] yeah. [21:35] hm. i find myself missing `bzr shelve`. [21:36] git stash :) [21:36] and it's cousin, git pop [21:37] hmm I really have no idea how to debug/fix this network issue.... [21:37] guess I won't be fixing it today :) [21:39] git stash doesn't do quite the same thing. [21:39] oh? [21:39] I thought they were almost identical [21:39] what is the difference? [21:39] if i have several chunks of changes in one file, bzr shelve lets me shelve them selectively. [21:40] stash is just "what's the WIP? let's stash it" -- or at least appears to be that. [21:41] ahh yeah, I didn't know bzr shelve did that. How does it determine where the chunks are? [21:41] bzr diff, grab each chunk [21:42] ok so basically wherever there is a line which isn't changed is a divider [21:43] I could see that being useful [21:43] there has to be a way to do that with git [21:43] ....you can do everything with git somehow :) [21:51] so you can git stash only a single file if you have edited multiple [21:52] but I can't find any way to stash parts of a diff [21:52] oh wait [21:53] `git stash --patch --no-keep-index` [21:53] ^ jcsackett you can try that [21:53] hatch: alright, i'll give that a go. [21:53] you might need to use `save --patch` [21:53] but maybe not [21:54] https://www.kernel.org/pub/software/scm/git/docs/git-stash.html grep for --patch for more info [21:54] I knew there had to be a way haha [21:55] apparently `git stash -p` works exactly like what you're asking....but I can't find any docs to back that up [22:01] jujugui quick code review for demo-able deployer button - https://github.com/juju/juju-gui/pull/259 [22:02] jujugui also, confirmed the CI failure was an unrelated timeout on https://github.com/juju/juju-gui/pull/253 [22:04] Makyo review done - I can't QA unfortunately [22:08] ahah fixed the network issue [22:08] Makyo I can QA now [22:08] anyone recall the guiserver url? [22:08] guihelp ^ [22:08] hmmm [22:09] mind.....is......blank [22:09] rick_h_ like you want to access the guiserver not the gui? [22:10] hatch: nvm, I think I'm close now [22:10] ok cool [22:11] hazmat: I don't think it'll work. I don't know the core internals to tell but trying to force the icons to the store is easy, but the data isn't there in the api [22:12] hazmat Makyo I'm going to start walking to the meetup at about 4:30 [22:12] Sounds good. [22:12] hazmat: pita, but think https://docs.google.com/a/canonical.com/document/d/1Y8Uhomr4_6L3nFXLXPZY2V-tFjl5KjOIknQLuXdzU_A/edit might be the best bet for the demo so that you can ingest the charms in that local store and provide the icons [22:13] hazmat: unless there's something in the core api for the files that will allow this to work for non-local charms [22:13] hazmat: https://ec2-54-87-142-1.compute-1.amazonaws.com/juju-core/charms?url=cs:precise/juju-gui-90&file= is the url for getting a list of the files [22:13] fixed the network issue now only to have other stuff break....bleh [22:14] hazmat: obviously change to your url/etc [22:17] Makyo: jcsackett so both of you need qa? [22:17] looks like it [22:17] Yes please. [22:17] I'll try and get mine up and running when we get back [22:18] Makyo meet you in the lobby? [22:18] Yep, down in a few. [22:18] ok cya all [22:20] Ducking out too. Will catch up later, possibly while there. [23:01] Hi rick_h_ Can I have a minute of your time? [23:02] Morning [23:06] I am doing a charm review, and Jose added defaults to the config.yaml for juju-gui. https://code.launchpad.net/~jose/charms/precise/juju-gui/add-blank-defaults/+merge/212885 [23:07] Normally this is not a problem, but I have encountered charm authors who counted on some parameters to be "unset" and I was wondering if anyone in the juju-gui would like to weigh in on this? [23:10] Specifically the config options that he now defaults to "" are: ssl-cert-contents, ssl-key-contents, login-help. Does anyone know if the juju-gui depends on those 3 being unset rather than empty string? [23:10] also password [23:53] mbruzek: sure thing [23:54] mbruzek: we've got a task to look at unset itself. The defaults should be ok as "". I don't recall if we'll send them as "" or not [23:55] mbruzek: honestly, I'd try it out and see. I think the unset we need to do is to reset a config where they expect it to be unset [23:55] if he's defaulting to "" then he's expecting that?