[00:21] huwshimi: back - so any q's? [00:24] hatch: Hey [00:25] hatch: I was wondering why you removed the "Y.one('.left-breakout').addClass('with-charm');" [00:27] I removed the style too and put the width on the container [00:27] but the root of the reasoning is [00:27] ... [00:28] the 'render' method of the viewlet is responsible for generating it's own markup, not to influence things outside [00:30] hatch: Ah, I see the width was cached, I just refreshed and it works now :) [00:30] excellent :) [11:15] hey guys [11:15] I am having a hard time finding the URL for the juju-gui [11:15] https://jujucharms.com/charms/precise/juju-gui/ doesn't work [11:16] morning jcastro. try http://manage.jujucharms.com/charms/precise/juju-gui [11:16] no I mean for normal people [11:17] like, the results from google URLs don't seem to work for me [11:19] https://jujucharms.com/precise/juju-gui-HEAD/ seems to work? [11:19] https://jujucharms.com/precise/juju-gui takes me to the wrong charm? [11:21] jcastro: yeah, you're right. that last URL takes you to juju. i wonder if there is an error in the parsing where the '-' is throwing it off [11:22] you always have to have a versio number [11:23] there's a bug in truncating juju-gui without a version number because it wants to think that juju is the charm with a version of -gui [11:23] every single URL I'm clicking from google is broken [11:23] if I can even find it [11:23] I still don't understand why we broke every single URL [11:23] I mentioned at least 1000000 times that we can't break URLs [11:23] because we didn't get around to fixing them all. [11:24] we fixed most of them with redirects recently, this one didn't make it. It's still in the 'we need a url for HEAD and what's that to be' mode [11:24] I was assured over and over that these weren't going to break [11:24] and NOW if you search for any service + charm you can think of the #1 hit is github [11:24] except for wordpress, which returns the oneiric version the charm. :-/ [11:25] yea, we've got a task to work on making the gui crawlable by google in a proper way but it's not been worked on [11:25] there's a bunch of work to try to make the JS driven site indexable [11:26] I am giving a class today for people to deploy the GUI [11:26] and I don't have a way to link to the instructions [11:27] https://jujucharms.com/fullscreen/precise/juju-gui-1/#readme [11:29] rick_h: thanks for your review. IIUC you are suggesting to just add the is_subordinate field to the json file, correct? [11:30] frankban: correct, I know we were doing some ampping of that field but I think that was old charm model stuff [11:30] frankban: but for that kind of purpose. Just a sanity check that the json -> model is correct while it's doing this [11:30] frankban: the field should be in the current json, just has to be swapped to true vs false [11:32] rick_h: aha!, so, rather than changing the charm attr, change the value in data before creating the charm, right? [11:32] frankban: correct, I think that's a slightly 'better' test in case something in the model/json changes [11:32] rick_h: sounds good, thanks [11:32] but completely optional/suggestion [12:00] * frankban lunches [12:12] jcastro, (1) the link for the juju-gui readme is https://jujucharms.com/fullscreen/precise/juju-gui-head/#bws-readme . (2) we agree that the links were not handled well. this was something I cared about a lot as well. my take is that we did not clearly identify qa and acceptance tests as we should have, but ths is a discussion that the team will have. we will talk about this friday as a failure that we need to im [12:12] prove with process for the future. we are fixing the links, and we fixed a large chunk of them last week. (3) the search issue has been known for some time, and there's been a blueprint to fix it that was and is scheduled to be addressed in August. https://blueprints.launchpad.net/juju-gui/+spec/servercloud-s-juju-gui-charmbrowser-search-rankings [12:22] benji, any progress on #1206260? [12:22] <_mup_> Bug #1206260: GUI charm does not handle browser cache properly [12:24] I'm redeploying now to try again [12:24] benji ok. using ~juju-gui-charmers this time? [12:24] yep [12:25] cool thanks benji. [12:25] gary_poster: wait, let me verify: that is the one you get if you don't use a local charm, right? [12:25] frankban something to consider with charm server is that we need to support upgrade [12:26] benji, depends on how you deployed. if you said juju deploy juju-gui you are fine. what deploy spelling did you use? [12:27] yep, that was it: "juju deploy juju-gui" [12:27] benji, cool, s'good [12:27] k [12:28] bcsaller, this is your London sprint spreadsheet reminder :-) [12:43] gary_poster: the thing is we already have google juice for the "pretty" URLs, the /charms/precise/wordpress ones [12:44] jcastro, I've been checking. we had (thought we had?) a fix for this deployed last Friday. I'm looking at in in prodstack configs right now. I'll ask curtis about it when he gets in (hopefully 17 minutes) and hopefully he can figure out what went wrong, and get it fixed very soon, possibly within the hour if we get IS attention/resources. [12:45] gary_poster: the /charms fix didn't go in because the apache rewrite rule would interfere with the jujugui routing [12:45] gary_poster: that fix has to be made to charmworld itself [12:45] to support the /charms route and lack of a version number [12:45] rick, this one? [12:45] RewriteRule ^/charms/(oneiric|precise|quantal|raring|saucy)/([^/-]+)$ /$1/$2-HEAD [L,R=301] [12:46] gary_poster: oh hmm, they had one more general than that I had thought. [12:46] gary_poster: so nvm [12:46] rick_h, cool, ack [12:53] jcastro, rick_h the redirect is deployed. it works great for wordpress and mysql (e.g. https://jujucharms.com/charms/precise/mysql and https://jujucharms.com/~hazmat/precise/mysql). trailing slashes and hyphens confuse the redirect. we will address. But for now, this is only broken for charms that have hyphens in their names [12:53] gary_poster: I had checked last week too, it just wasn't until I tried to google the readme for the gui this morning when I realized I couldn't find it [12:53] sorry hazmat :-P [12:53] jcastro, yup, hyphen [12:54] apache redirects are great for bandaids but are not conducive to automated tests [12:54] gary_poster: ah, makes ense. the rule has ([^/-]+) [12:55] gary_poster: morning. re charm server and upgrade, do you mean changing the gui source option or upgrading the charm? how do we want to handle that? [12:55] rick_h, yup. we need to add a /? at the end and figure out a lookahead way to spell "not -\d+" [12:55] gary_poster: yea, was just thinking on that and my brain started hurting with lookaheads :) [12:55] frankban, upgrading the charm. changing the gui source is the same as always, I'd guess. [12:55] jujugui tiny review plaese for bug #1202636 https://codereview.appspot.com/12102043 [12:56] <_mup_> Bug #1202636: Charm Details Page Under Providers Change Openstack to HP Cloud [12:56] rick_h: ok [12:57] thanks bac [12:57] frankban, so, if someone upgrades from a charm pre-our-server then everything should still work hen they go from apache to tornado. [12:57] frankban, important for jujucharms.com [12:58] and for long-running gui charms [12:58] rick_h, I looked and code looked good. however was worried: test and code showed openstack + hp, but that's not what we are seeing in actual app. any idea why? [12:58] gary_poster: ack. so we will need extra-care when switching from the legacy servers to the experimental one [12:59] rick_h, sorry I meant in the branch before your changes [12:59] frankban, exactly [13:01] rick_h: code looks good. i did not QA [13:02] gary_poster: sorry, which test? [13:03] gary_poster: not following. before my changes we showed both openstack and hp? That's correct. That's what we were doing. If openstack tests failed we showed the user that both openstack and HP would not work. [13:03] gary_poster: now the user will never see 'openstack' in any provider info. [13:04] rick_h, if I go to https://jujucharms.com/precise/glance-18/ [13:04] I only see openstack [13:04] not hp [13:04] that's my concern rick_h [13:04] gary_poster: ah, that's because there was a bug from when huw redid to show passing providers [13:04] the code previously only showed failing providers [13:05] so the hack to 'make openstack mean both hp and openstack' was only in the model code for failing cases [13:05] gary_poster: that's part of my branch to make it consistent on both passing/failing [13:06] gary_poster: peek at https://codereview.appspot.com/12102043/patch/1/1004 and notice that only the !== SUCCESS did the openstack check before [13:06] rick_h, cool thanks. will make trivial suggestion but otherwise cool [13:06] yeah saw thanks [13:06] gary_poster: rgr, thanks [13:11] gary_poster: I have reproduced the cache problem and at first blush it looks like the problem simply is that we do not provide any cache control at all. [13:11] benji, duped: great!! no cache control: I thought we had ETags? [13:11] I saw them [13:12] are they just timestamp generated by something in the stack and not actually content generated? [13:13] we have ETags in the apache charm config, pretty sure [13:13] gary_poster: we have etags, but I don't think they imply a cache directive. [13:13] benji ok. sounds like an easy fix then, as I had hoped. yay! thanks [13:13] rick_h, doing qa now [13:21] gary_poster: I propose we add no-cache headers to the world; shall I create a branch to do so? How will that interact with the new server? [13:23] benji, how does a no-cache header interact with etags? I want files to be cached but I'm ok with ETag checks. [13:23] benji, branch: yes. [13:23] no-cache means not to ever cache :) [13:23] benji, I thought so. don't want that if we can help it. [13:24] benji, new server: let frankban know what we settle on here so he can mimic [13:25] gary_poster: we can add a must-revalidate instead which I am pretty sure will give us the desired effect now, but I don't know how much work it will take to support in the new server [13:25] benji, I know ETags are essentially free in new server [13:25] gary_poster, benji: that's also my understanding [13:26] benji, +1 on must-revalidate. should we test for downsides, or consider any? [13:27] other than testing to see if it works as expected, I can't think of anything. I'll do a little research. [13:27] rick_h, qa bad. getting you details and suggestions. [13:27] benji, perfect thanks! [13:28] gary_poster: ok, thanks for the catch. [13:28] btw: a no-cache across the board doesn't look that bad; we load all resources while the WS is connecting, which takes so long that everything is loaded by the time we connect to the environment (on chrome, on my machine, with an empty cache at least) [13:29] the problem there is users on slower bandwidth. I demo'd jujucharms.com from a coffee shop and it hung for a nice time. [13:29] benji, also there is no WS on jujucharms.com [13:29] I thought it was broken at first it was so much slower [13:30] hmm, we might want to have a card about evaluating low bandwidth (or more likely high latency) performance [13:30] benji, +1 [13:30] I'll add one. [13:31] benji, thanks. meanwhile, let's keep our cache! we have some relatively big files [13:31] k [13:33] rick_h, gave you details in review. the changes I give in diff fix qa exprience but, as I'm sure you'll see, will certainly break tests [13:33] rick_h, feel free to discard, as I said [13:34] ah, the links. Doh, and I knew the mismatch would bite us on the back side. [13:34] gary_poster: thanks, I did a similiar thing just now with the filters as I had msised that those would need to be updated. [13:35] rick_h, ah cool [13:35] keep forgetting they're still there :/ [13:37] abentley, bac: I need a mid-implementation review of nagios branch. I'd like some direction about the nagios checks and tests: https://code.launchpad.net/~sinzui/charms/precise/juju-gui/nagios/+merge/177588 [13:37] sinzui: ok [13:37] bac: if you are not familiar with the nagos situation in prodstack, be prepared for a shock [13:38] sinzui: i know only what you described in raleigh. [13:38] * bac dons helmet [13:44] sinzui, we need to adjust our jujucharms redirect regex, ideally this morning--so, asap, but not unduly interrupting anything. lemme know when you are available to discuss [13:47] gary_poster, I expect to be free in 45 minutes. I foresee any issues updating apache. We just need to know the rules to verify locally and in production [13:47] sinzui, cool. working on them and will give them to you for verification. thanks [13:47] I don't foresee an issues I mean [13:48] morning all, still lf 2 reviews https://codereview.appspot.com/12071043/ [13:50] hatch, morning, was looking at that back ages ago :-P sorry. best to find someone else now--booked for next 2.5 hours [13:50] no problem :) [13:54] sinzui, I have a call now, so I will describe problem here so you can look at it. charm names with hyphens do not work properly with the current redirect rules. this breaks the juju-gui redirect, for instance. Also, charm names with trailing slashes do not work, but these do not work in m.j.c so less of a priority. Examples of urls: [13:54] https://jujucharms.com/charms/precise/juju-gui [13:54] https://jujucharms.com/~juju-gui/precise/juju-gui [13:54] https://jujucharms.com/charms/precise/wordpress/ [13:54] we will need a lookahead assertion for the first problem [13:54] this seems to work for me: [13:55] re.match(r'^/charms/(oneiric|precise|quantal|raring|saucy)/((?![^/]+-(\d+|head|HEAD)/?$)[^/]+)/?$', '/charms/precise/juju-head-57/') [13:55] I tested that with a variety of options. [13:55] I think it might mess up the $3 though [13:56] thank you gary_poster [13:56] thanks sinzui! [13:59] re.match(r'^/charms/(oneiric|precise|quantal|raring|saucy)/((?![^/]+-(?:\d+|head|HEAD)/?$)[^/]+)/?$', '/charms/precise/juju-gui/') better for groups fwiw [14:15] gary_poster: bac updated the branch per the QA issue gary brought up. Redid the solution a bit. It's both simpler and more complex. https://codereview.appspot.com/12102043 [14:15] appreciate another look when you get time. [14:15] so I was looking at some of the juju-core code - can you not run Go statements on multiple lines? 8 space indentations? [14:15] rick_h, if you can get someone else would be great. busy for 2 hours [14:16] hatch: care to swap some review time please? ^^ [14:16] hatch: see the history as gary brought up some issues on the first go-round [14:16] mine is shorter - you have to do mine twice [14:16] :P [14:16] hah! [14:16] sinzui: where is check_ingest.sh? or is such a check the thing you'd like to discuss? === BradCrittenden is now known as bac [14:16] hatch: link me up [14:17] https://codereview.appspot.com/12071043/ [14:18] old chunk mismatch? boooo now you owe me back since mine at least loads :P [14:18] lol [14:19] rick_h: little odd that openstack == hp no? [14:20] hatch: no, we run charm tests against three platforms. lxc, ec2, hp cloud. hp cloud is called 'openstack' in testing because that's what hp cloud is running. [14:20] ohh and ec2 doesn't run openstack? [14:20] i thought they did [14:20] no [14:21] they must run closedstack [14:21] it's closed source brother [14:26] benji: Morning. [14:26] good morning [14:26] man I really wish npm cache worked on my desktop [14:26] make takes for friggen everrrrrrrrrr [14:27] benji: re: https://code.launchpad.net/~benji/charmworld/bundle-indexing/+merge/176956 you don't need more than one "approve vote". Those rejections about unapproved revisions were about the "Approved revision", which is set by twiddling "Status". [14:28] hatch: have you tried setting it globally: npm set cache-min=9999999 [14:28] benji: I can try [14:28] abentley: good to know; I was very tired of fighting the bot there [14:29] benji: still no luck :( [14:29] benji: It kinda looked that way ;-) [14:29] :) [14:29] hey rick_h, in the template you call like {{prettyProvider . }} -- how's that work? '.' is passed as the id? [14:30] bac: yea, it's the current scope atm. You'll see that the before was that already. [14:30] . == current scoped object which is the provider [14:31] hatch: you might look at the results of "npm config list" and see if there is anything odd there [14:31] yeah nothing out of the ordinary there either [14:34] rick_h: so as long as the providers show up with proper names and are clickable that's a successful QA? [14:34] hatch: yes, the failing qa last time was the broken links on the provider names [14:34] hatch: in qa'ing your branch clicking cancel still puts a service icon on the canvas? [14:35] sure it's still not a ghost? [14:35] hatch: but it does that on jujucharms.com so LGTM'ing it I guess. Known bug? [14:36] hatch: yea, but I'd expect a clean canvas as it works now w/o the inspector flag [14:36] rick_h: sorry, i got dropped out of irc after asking that question. if you'd answered please do so again [14:36] bac: . == current scoped object which is the provider [14:37] rick_h: yeah it's still a ghost - there will be a 'destroy' button on here somewhere to remove it [14:37] bac: there's some notes on scope in the handlebars docs http://handlebarsjs.com/ search for 'scope' [14:37] cool [14:37] hatch: but why is it there anyway? I cancled the deploy? [14:37] bac: I'm not a fan of using . but just kept it since it was used there already [14:37] the UX makes no sense to me hatch especially when it's a change from non-inspector behavior [14:37] rick_h: ahh according to the wireframe 'cancel' should read 'save' [14:38] see V11 [14:38] hatch: huh? drag a charm to my canvas and get save/confirm? [14:38] save/next [14:39] wtf does save/next mean on a deploy step. now I'm really confused [14:39] although that section has changed in almost every revision of the mockups so who knows what it'll be in the end [14:39] ok, well LGTM'd and noted with a wtf carry on :) [14:41] :) [14:41] yours as well [14:42] sinzui: I'm thinking maybe we should disable dynamic mappings for elasticsearch. Since we specify which fields to search on, indexing an unexpected field does us no good (unless we later decide to expect it). And it could seriously simplify our mapping (currently 457K, pretty-printed). [14:43] abentley, +1 [14:43] sinzui, abentley I added a comment to bug 1199780 -- could you tell me your opinion? [14:43] <_mup_> Bug #1199780: search requests errors when a charm has no last_change [14:44] jcsackett, hangout? [14:48] sinzui: invite on the way. [15:01] jujugui will come by bundle call asap. almost done [15:02] sinzui, abentley: coming to bundle call now? [15:02] bac: Trying. Google hangouts wants me to install the latest version of the plugin. [15:03] is this in guichat? [15:04] hatch, oops, didn't see your review on Huw's branch. 3 LGTMs is better than 2, I guess. gary_poster, want me to land that? [15:04] Makyo, +1 thank you [15:04] already landing [15:04] Makyo: gary_poster [15:04] Oh [15:04] in fact....it's landed [15:05] Good luck. We're all counting on you. [15:05] \o/ [15:05] lbox submit -v -adopt [15:05] awww yeah [15:05] * hatch read the help file [15:05] Haha [15:06] * hatch pokes his head in all of the offices trying to find the deployer hangout [15:07] hatch, wasn't it part of the invite? [15:07] https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.ckc3m4182f9qqffjqh2p259d6k?authuser=1 [15:08] bac, sorry, 1 script, 2 names. I need to delete/replace one of the scripts. either the hook or the file in scripts [15:08] hatch ^^^ [15:08] thanks [15:15] jujugui - lf one more review https://codereview.appspot.com/12071043/ [15:19] rick_h: fyi - I'm working on the destroying the ghost part now [15:20] hatch: all good [15:34] jujugui one more review, please https://codereview.appspot.com/12060044/ Mostly mechanical/policy wrt flags in tests [15:34] Makyo: looking [15:34] rick_h, thanks. [15:34] Makyo: while you're waiting you can review mine :) [15:34] Makyo: card? [15:35] * rick_h is trying to be a good card tagger [15:35] rick_h, Down in slack, help tests run in isolation. [15:35] Experiencing problems installing juju-gui charm (unit.hook.api INFO: Retrieving Juju GUI release). Get connection timeout to Launchpad [15:35] Makyo: ah, cool to drag to review then? [15:35] rick_h, oh, yeah, sorry! [15:37] jujugui ^^^ Is there a way to get that to run again? Maybe upgrade-charm? [15:38] will try. using juju v0.7 if that makes a difference. couldn't get juju-core to work (CA certificate error). [15:38] when issuing any juju command [15:39] Is there only a cs:precise/juju-gui charm? [15:40] alove, that's the promulgated one, yes. [15:41] ok. will continue to try with that one. [15:42] Makyo: what was the aversion to after() reasoning? [15:42] I see comments asking for it but I'm not seeing the thought behind it. [15:42] alove, you can juju set juju-gui-source=0.8.1 to try to get the GUI release again. [15:43] Makyo, thanks for the config tip [15:43] rick_h, my understanding was that it maintains hygiene between tests, rather than just between suites. [15:45] Makyo: yea, the hygiene phrasing I don't follow I guess. We don't reset namespaces or modules/etc. [15:45] Makyo: but cool, just curious [15:45] rick_h, yeah, I'm curious about that as well, added a card for discussion, [15:45] ah cool [15:50] jujugui call in 10 kanban now [15:51] hatch, lgtmd [15:52] Which sounds like a service. sudo service lgtmd restart [15:54] typical unix name [15:54] abreviate all the things! [15:57] jujugui guichat in 3 [15:58] LGTMSE~1.EXE? [15:59] ohhh DOS [15:59] file to long...I'll just truncate it for you mkay? [15:59] I suppose that's better than linux alowing you to rename files to an empty tring lol [16:00] jujugui guichat call now [16:05] hazmat we need your yaml fix landed today. want us to do last changes and land it for you? [16:14] Makyo, Done - juju set juju-gui juju-gui-source=0.8.1 [16:14] foloowed by - juju upgrade-charm juju-gui [16:14] alove, did that work this time? No LP troubles? [16:14] got - ERROR Charm 'cs:precise/juju-gui-68' is the latest revision known [16:15] alove, okay. The second step doesn't sound like it'll be necessary in the future, since you're already up to date. Did the config changed hook work [16:16] ? [16:17] Makyo, yes. when I do a juju get juju-gui I see value: 0.8.1 [16:17] jcastro, you around? [16:17] frankban: is that your typical daily view? out that big window? [16:17] alove, alright. Does juju status still show the unit in error? [16:18] hatch: no, I am not in the usual place [16:18] gary_poster, working on it now [16:18] Makyo, yes. agent-state: install-error [16:18] hazmat, awesome thanks [16:18] frankban: ahh too bad, looks like it's a nice view.... [16:18] hatch: indeed! [16:19] gary_poster: yo [16:19] jcastro, hey can you join http://tinyurl.com/guichat for 5 min or less? [16:19] yeah [16:20] jcastro about all category [16:20] thanks [16:21] sinzui: when/where is the ornage call? [16:22] adeuring: not sure about where, but when is after rick_h finishes his call, i think. [16:22] ok [16:23] Makyo: Just some context. Running MAAS master on Raring, Juju boostrap unit on Raring, Juju-gui unit on Precise. Juju 0.7 [16:24] alove, I think you should be able to retry the failed hook with juju resolved --retry juju-gui/0 [16:24] jujugui please check me on this. [16:29] jcsackett: to QA this branch everything should appear to work as normal? [16:30] adeuring, https://plus.google.com/hangouts/_/614754f01c23d91c52a3c1bfea258b7f9f8fdc0d?hl=en [16:31] Makyo, alove yes that would retry. however, alove it sounds like you are working behand a firewall? [16:31] behind [16:32] hey rick_h or gary [16:32] jcastro, yo [16:32] those URL rewrites, those are 301 redirects? [16:33] jcastro, yes. [16:34] gary_poster: I am behind FW however have installed packages on juju-gui unit manually from repos successfully. Doing a netstat I can see tcp 0 1 192-168-56-101.clouddomain:52515 launchpad-net.nutmeg.canonical.com:https SYN_SENT [16:36] alove, yeah that looks like the problem. you need to get the GUI tarball someplace that MAAS can reach it. Here's one approach: [16:36] 1) download tarball from https://launchpad.net/juju-gui/stable/0.8.1/+download/juju-gui-0.8.1.tgz to somewhere [16:37] 2) put it somewhere on your network that your MAAS cluster can connect to [16:37] that needs to be either accessible via a http or file [16:37] so [16:38] you could put it on the filesystem of the GUI service [16:38] or you could put it somewhere with a static server accessible [16:39] 3) if you used a url, "juju set juju-gui-soure=url:http://PATH TO TARBALL" [16:39] if you used a file, change that to url:file:///PATH [16:39] 4) do that retry Makyo gave you ("juju resolved --retry juju-gui/0") === schwuk is now known as schwuk_away [16:40] That should do the trick, if everything is connected properly [16:40] alove, ^^^ done [16:41] gary_poster: Many thanks. I'll give that a go now using the filesystem method. [16:41] gary_poster, should I do a quick docs branch with that? [16:41] alove, cool. that should have been "juju-gui-source" not "juju-gui-soure" [16:41] typo, sorry [16:41] np [16:42] Makyo, yes, thank you. Maybe we should bite the bullet and stick the GUI in the charm too :-/ [16:42] as the default source [16:42] for these firewall situations [16:42] gary_poster, maybe when we hit 1.0? [16:42] Yeah [16:42] Makyo, yeah, maybe so [16:42] gary_poster: I've verified that my tweaked charm correctly sends new css/js after an upgrade and it also sends 304 Not Modifieds when no upgrade has happened since the last browser request [16:43] benji, yay, thanks! [16:43] we should have some sort of test to enforce this behavior, but I think I can add that to the charm tests pretty easily (especially considering that we're changing servers and my change is an Apache config tweak) [16:43] hatch: sorry for delay, was OTP. yes, everything should work as before, and should work in rapi mode as well. [16:44] benji, that would be great thanks [16:44] benji, are you happy with this cache behavior as a sane choice? [16:45] gary_poster: yep, it should work very well; I am worried about the non-gui servers we depend on though; I believe they do not behave well (jujucharms.com, for example) [16:45] benji, how so? you are afraid that they will mess up our cache headers? [16:46] benji fwiw, we still use our charm's apache, but it is fronted with another apache that provides the https [16:46] on jujucharms [16:46] nope, I'm afraid their headers have the same problem as ours and changes, to e.g., default and category icons, won't be reflected in the gui [16:48] benji, oh! I see, you meant manage.jujucharms.com [16:48] oh, right [16:49] and it wouldn't be the category and default icons it would be the charm icons [16:49] benji, ack, I will add card. actually both are pertinent: we changed default icons too lately (added color) [16:50] gary_poster: you are a star ... install is now progressing to retrieve Juju API source checkout ... but may have similar problem [16:52] alove, yay! but yes, may be an issue. That's PyJuju, not Juju Core. :-/ um. lemme know if it does turn out badly and I'll think about it then :-) [16:53] gary_poster: yep, same timeout problem [16:54] ack, 1 sec [16:55] ok, looking [16:55] um [16:55] gary_poster: sinzui highest priority todo from here? some url cleaning? mjc download numbers? the routing querystring dumping bug? remove filters from the UX? [16:55] alove soory, can pay attention after another 5 [16:56] sinzui, if you have suggestion for rick_h, +1. otherwise CSS transitions would have big bang for buck for upcoming demo [16:56] no problem, appreciate any help but don't worry if you're focused elsewhere. [16:57] rick_h, can help with desc later [17:06] alove, four options, none of them particularly attractive. (1) use bzr to branch lp:~hazmat/juju/rapi-rollup locally ("bzr branch lp:~hazmat/juju/rapi-rollup") and copy directory on the gui service machine; "juju set juju-gui juju-api-branch=PATH_TO_LOCAL_BZR_BRANCH" [17:07] (that's the best one; the rest get bad very fast :-P ) [17:07] 2) switch to juju core [17:09] 3) ...I forgot... [17:09] 4) hack charm to make it so that you can have the source embedded and give us the diff :-) [17:10] rick_h, are you good on goals? can talk through those. then going to go get some lunch and talk a walk :-) [17:11] * gary_poster hungry. [17:11] biab: walk and lunch [17:12] gary_poster: I'm goign to grab food as well. Ping me when you get a sec then as I thought huw was doing animations and had some WiP. Happy to help move that forward though. [17:14] gary_poster: I'll try 1) ... tomorrow. Bailing out now (UK!). Thanks to you and Makyo. [17:15] quit [17:16] jujugui docs update for charm re: discussion with alove https://codereview.appspot.com/12120043 [17:28] gary_poster: we should get some of these for when people can't join us for the sprints http://romotive.com/ [17:40] when a ghost is destroyed should we throw up a confirmation? [17:52] hatch: i don't think so--the ghost disappearing from the canvas should be sufficient, don't you think? [17:52] my concern is that you go to click 'save' and accidentilly hit 'destroy service' [17:52] after you have spent x time setting your config [17:53] but the ux puts the 'are you sure' message at the top of the inspector... [17:53] the complete opposite side of the button [17:56] fyi node-inspector has new authors and is now being updated again https://github.com/node-inspector/node-inspector yay! [17:57] hatch: ah, that's cool. Using chrome remote debugging to hook into a node script? [17:58] yup it's been stagnant for so long [17:58] finally been picked up again [18:00] I think I'm going to take some developer license and make my own confirmation popup [18:01] maybe that should be in a follow-up though [18:01] yeah [18:03] oh we have a destroy template already [18:03] maybe I'l use that [18:31] hatch, romotive, heh +1 [18:32] I talked with a guy at PyOhio that worked for bump and they got him a tele-robot for a few months to try out. [18:32] said it was more akward than anything, ended up sending it back [18:32] rick_h, maybe you are right about transitions. hatch, was Huw going to go back to transitions after you talked with him, or is that something for someone else now? I thought it was for someone else [18:33] gary_poster: yea, I've been hunting for some docs on animations and coming up empty. I know hatch and I had a chat at one point regarding huw's work on them and a demo someone else had. [18:33] gary_poster: for someone else to tackle - it will require markup/styling/scripting changes to how the browser functions to achieve the desired effect that UX wants cc/ rick_h [18:33] maybe my google-doc-fu is weak [18:33] rick_h, I just think it would be funny :-P . no guidance on practical [18:35] rick_h, ack. looking for firefox demo [18:37] rick_h, https://dl.dropboxusercontent.com/u/10004366/juju-gui/index.html# has annimations [18:38] -n [18:38] loading [18:38] rick_h, animations include: [18:38] - hovering over tab [18:38] - clicking on tab (in both sidebar and sidebar + charm positions) [18:38] hmm, no worky here [18:39] rick_h, FF only [18:39] ah, the mixed content was blocked so FF didn't load it [18:39] - clicking on charm (opens charm panel) [18:39] - orange bar slide (build/browse) [18:40] note that the orange bar slide is also used in the inspector so building that one generically would be nice [18:40] espcially because browse/build might die :-P [18:40] ah, ok [18:40] rick_h, hatch might have more insight. also if this is not interesting, tell me so. plenty of other things to do [18:41] gary_poster: it's cool, just peeking over demo. [18:41] rick_h, great [18:41] gary_poster: ok to land incrementally? [18:41] the cool thing about the tabbed slide results is that we can get rid of that tabview....mohohahahaha [18:41] * hatch ducks [18:42] tabbed slide? [18:42] rick_h, big +1 on incrementally [18:42] gary_poster: k cool then [18:42] hatch: shush [18:42] gary_poster: I would like to bring up hatch's concerns on that tab vs the previous policies of making the tabs url/direct loadable [18:42] as it's costing us in maint. time/effort a bunch lately [18:43] and wondering how worth it it really is [18:43] * rick_h needs to find a way to avoid 'it it' in the future [18:43] heh [18:43] rick_h, unclear on what you are advocating discarding [18:44] right now when you click a tab in charm details the url adds the hash attribute #bws-readme [18:44] that's caused us to complicate routing and this back button behavior bug that hatch filed [18:44] we're trying to do two different things. On one hand, each tab is it's own url/resource. On the other, we want to back button and not treat it as so. [18:44] and now we have to kill that feature in the shared code in the inspector charm details [18:45] the 'work arounds' are adding up and I wanted to see if we could sit down at some point and re-evaluate it. [18:45] "we want to back button and not treat it as so": you mean we don't want to back button across tabs? [18:45] I would guess we do [18:45] gary_poster: correct [18:45] I'll be available for a chat whenever if you guys want to discuss [18:45] and we don't want it on the inspector version [18:47] well, the inspector simply can't mutate the url; I'd argue that's a reasonable difference. but...why did we decide that tabs should not participate in back-arrow? FWIW, here's my expected behavior: [18:47] each tab is another url, with an actual url element [18:48] they are handled as usual in both back arrow history and everywhere else. so "/bws_readme" not "#bws_readme" [18:48] to be clear, [18:48] I'm not saying that we have to do that now [18:48] gary_poster: ok cool [18:48] but if doing that is as easy as other options then that would be great [18:48] IIUC, [18:48] well the animatino for the tabs would involve getting dirty in that code [18:48] which is why I bring it up [18:48] because we'd probably ditch the YUI TabView we're using and go another route. [18:49] it'll be 100x easier without that tabview [18:49] right [18:49] it's just not built for that interaction [18:49] is the tabview buying us much? relatedly, will replacing it be expensive? [18:49] agreed, ok. Well that helps clear it up. hatch can you update your bug with those notes then? More that tabs should be /tabname vs #tabname and not about back button? [18:50] gary_poster: well it's doing the 'fold content into tab defined, click, fire event on change' stuff for them. [18:50] gary_poster: so it'd have to be replaced with some sort of more carousel-like widget with the animations but same click/change of display events we use for tabs. [18:52] rick_h, ack. that sounds pretty basic on the face of it [18:52] ? [18:52] gary_poster: sure thing. We actually had a carousel widget we dropped at the start of the project we could start with. [18:53] but ok cool, hatch updates his bug, I'll start poking at the animations. Thanks for the walk through. [18:54] and the animations demo works under chrome once you ditch https on the demo url :) [18:54] hurray, the carousel we worked on might not be useless after all. [18:55] jcsackett: woot, now to find it :/ [18:56] rick_h, ok, thanks. go for relatively quick wins--if something looks doable in a day (start to land), it's worth it. Otherwise, if something looks not quick, hold off, and maybe file a bug with details? [18:57] jujugui does anyone know how I access topology ServiceModule methods from app.views.environment.instance.topo ? [18:57] gary_poster: rgr [18:57] hatch, I believe's bcsaller's intent is events, or refactor [18:57] hatch: what are you trying to do? [18:57] hatch, events. [18:57] HULK SAYS EVENTS BAD! [18:57] lol [18:58] ok but for real :) [18:58] Oh for Pete's sake. [18:58] Events. [18:58] hatch: shush with your lies [18:58] the serviceInspector destroy service needs to hide the service context menu in the environment [18:58] Pete's my neighbor. he's a history teacher. He likes events. [18:58] events good! just need to use events responsibly [18:59] hatch, fire the clear events. Just a sec, Ill get the spe [18:59] c [18:59] hatch: so who's above both the serviceInspector and the context menu? [18:59] it's his job to handle it [18:59] clearState [18:59] there is clearState [18:59] ahh :) [18:59] so fire that from topo? [18:59] Yep [18:59] werd [19:01] sawlid [19:01] Choice. [19:02] way to proper [19:02] Tops. [19:02] choice [19:02] no caps, no period [19:02] tops lol [19:02] Nah, pass. [19:02] I just really, really like my shift key :) [19:02] * rick_h shakes head at oddness of canadians [19:03] hatch: but when I was getting my car worked on in canada I got to watch canadian news and saw some singer didn't want to tribute your area man [19:03] oh yeah don't even get me started on that [19:03] hatch: I yelled at the TV "Hey, I've heard of that sack-a-toon place before!" [19:03] Hahahah [19:04] I only have expletives and derogatory comments to say about her [19:04] and canadian news should stop hiring so many vampires for their broadcasts. It was spooky [19:04] you were probably watching east coast news [19:04] CBC [19:04] ? [19:04] national? [19:05] yea, think it was national CBC. They did weather coast to coast [19:05] * rick_h was there a while [19:05] ahh yeah I think that's broadcast from Toronto [19:05] they were talking about "The premiers on lake on niagra" and I thought they were talking about a mo-town band [19:05] lol [19:05] ends up you guys have "The Premiers"...who knew? [19:07] shit now you got me all riled up about her [19:07] haha u suck [19:07] lol [19:07] if it makes you feel better I thought they were talking about a "He". Can't recall the name [19:08] http://www.torontosun.com/2013/07/26/joni-mitchell-calls-saskatoon-bigoted [19:10] Makyo, LGTM doc branch with comments. I say review my changes, adjust as desired, and land. [19:10] gary_poster, cool, thanks. [19:13] bcsaller, hey. sorry for bugging you on the London flight, but we are near deadline. you on that for today? [19:14] yeah, I'll finish that up today [19:14] sinzui: chat? [19:14] thanks [19:14] abentley, sure [19:16] sinzui: https://plus.google.com/hangouts/_/60b018b674fa86d972e739a8ffd245d09b882bbf?hl=en-GB [19:31] Makyo: bcsaller so the linter doesn't like me using app.views.environment.... from the inspector or from service.js because app isn't defined meaning I have to do a hack like `var app = app;` any ideas of non hacky workarounds? [19:32] you pass it down either the method you need or the object [19:33] hatch, bcsaller +1 app being global is a hack for debugging that we should, frankly, get rid of. Ditto yui, I think. [19:33] well we should keep it for debugging heh [19:33] ok can do that [19:34] Well, alrght. I think it's easier to debug in the standard breakpoint/callstack way, but that's me, maybe it's easier to have that around for debugging. [19:36] hmm nowhere that creates this stuff has easy access to the various components either [19:37] pooey [19:38] what is the object that needs access to the topo, its not created under the env view? [19:38] I'm pretty sure I have it [19:38] I just like to blab [19:44] ok so there is one issue [19:49] these charm tests sure do take a while to run [19:49] gary_poster, the redirects are live [19:49] awesome, thanks sinzui! what did you add? [19:50] gary_poster, this MP has the links we checked https://code.launchpad.net/~sinzui/canonical-is-charm-configs/hyphened-charm-redirects/+merge/177665 [19:50] gary_poster, your re + a variant to support users. [19:51] cool sinzui. the last 2 examples from qa list are not working for me. Trying all... [19:52] sinzui, yeah they all work except for last two [19:52] do you see the same? [19:53] I got a redirect for both [19:53] I was directed to https://jujucharms.com/precise/juju-gui-HEAD/ [19:54] sinzui, confirmed, thanks! I think I was hitting the cacheing bug that benji is fixing. [19:54] I just had to reload [19:54] :) [19:57] sinzui, I saw https://rt.admin.canonical.com/Ticket/Display.html?id=63590 . is this a big problem or a quick fix or we don't know yet? [19:57] gary_poster: can you pull my branch down and create/delete some ghosts/services to see if you agree with my engineering-license wrt the destroy service alerts lp:~hatch/juju-gui/deletable-ghost [19:57] lol yes hatch on it [19:58] :) thanks [20:02] hatch +1 pretty scroll. I don't care for the UX they gave for this but let's run with it for now and see where it goes. [20:02] thank you! [20:02] s/scroll/animation/ [20:03] excellent thanks - I'll now fix the tests [20:03] and propose [20:04] gary_poster, I have a fix, but it introduces a fault I need to chase down [20:05] sinzui, ack. would be curious about details sometime. maybe discuss at IoM. [20:09] gary_poster, This is the my MP with with m_3's report of failure: https://code.launchpad.net/~sinzui/charms/precise/mongodb/restore-from-dump/+merge/165408 [20:10] sinzui, :-/ gotcha [20:12] * hatch lunching [20:47] bcsaller, my EoD is coming soon. lest I forget, if you get the conflict resolution code landed today, could you send an email to Huw to get him to style it? [20:47] yes, I will do that [20:47] bcsaller, alternatively, if it is not landed but you don't expect big changes, you could send him the branch [20:47] cool tjank you [20:48] thank [20:48] thanks [22:38] jujugui Looking for two reviews and a QA on https://codereview.appspot.com/12050049 plz and thanks [22:39] Bueller..........Bueller...... [22:40] hatch: taking a look now [22:40] :D thanks [23:02] Morning [23:04] morning huwshimi [23:04] I landed your branch this morning [23:05] hatch: Oh thanks