[00:15] huwshimi ready for a final review/qa on #95? [00:15] hatch: That'd be great! [00:16] ok I'm going to take a little break then I'll get on it [00:17] hatch: Thankyou! [00:21] huwshimi trivial typo on the code review....ok now I'm really going to take a break before qa :) [00:28] hatch: "typeo: maximized" hilarious. [00:33] haha :) [01:33] https://github.com/juju/juju-gui/pull/101 ready for review, and now I run :-) === gary_poster is now known as gary_poster|away [01:57] huwshimi fyi we use a z instead of s in maximized :) [02:00] hatch: Do we? [02:01] huwshimi I don't know what version of English we use :) [02:02] hatch: Well, our writing style guides are for British English (we're a British company). Not sure if we have additional rules for our code comments. [02:03] qa ok! [02:04] huwshimi before you merge it in can you rebase it? [02:05] Sure! [10:11] morning hazmat: re: bug 1252301 do you already have a plan, can I help in some way? [10:11] <_mup_> Bug #1252301: guiserver reports second bundle as failing after the first fails

[11:23] frankban, i'm at sprint and then on vacation till roughly feb 17th, and then multi-tasking for partner/customer deadlines. [11:23] frankban, if you have time that would be great.. the simple thing is just to have wait for units methods, take flag, and pass the flag in via config.. i think.. i haven't thought about it while looking at the code. [11:25] hazmat: ack. there is already an ignore_error flag passed to that function [11:25] hazmat: I'll take a better look at it [11:27] frankban, thanks === gary_poster|away is now known as gary_poster [13:17] frankban: +1 on GUI login text PR 103 [13:26] gary_poster: thanks! [13:30] rick_h_: qa bad on your demo icon branch. To see problem, go to https://manage.jujucharms.com/api/3/charm/~web-brandon/precise/my-site-1/file/icon.svg?demo=true . Maybe "demo" is not the expected name in charmworld for this functionality? [13:30] welcome [13:38] hi benji, would you have a moment for some makefile advice? [13:38] bac: sure [13:42] gary_poster can we cancel the merge of huws branch or is it too late? It wasn't rebased [13:43] hatch, I don't know how, sorry [13:43] * gary_poster kinda hates the rebase thing. [13:43] * gary_poster kinda thinks bzr shoulda won [13:43] yeah I don't know how to cancel it either :) without the rebase bisecting is kind of a pita of unfortunately....having a bunch of broken commits [13:44] yeah this part bzr clearly wins [13:44] hatch I think I might have canceled it [13:45] gary_poster: bah, sorry. I assumed charmworld would ignore it. I tried to work on the charmworld side of the branch but the ppa's for charmworld aren't available for trusty [13:47] hatch: ok it is cancelled,pretty sure. I aborted build [13:47] hatch one of us should do the rebase [13:47] hatch I can try to delete it later [13:47] I mean rebase it :-P which may mean deleting huw's PR [13:48] (closing) [13:48] rick_h_: np. [13:48] gary_poster: will leave that on hold for the moment and will try to get an older release lxc setup to update charmworld first then [13:49] gary_poster: thanks for the review/qa catch [13:49] cool rick_h_ . OTOH If you want to land it with a "it's feature-flagged" approach that's fine with me too [13:49] gary_poster: will see what time I get. If it'll be a bit I'll add a FF on it [13:49] I wonder if we can write an intelligent rebase script so it could act like bzr [13:50] maybe should anyway since in order to land it would need a charmworld release :/ good call [13:50] rick_h_: IMO it is already "feature flagged": you have to opt in on the console [13:50] gary_poster: oh yea even better :) [13:51] hatch: ugh yea. I need to see if I can update the process to handle this. What we need is a clear process for "update from develop" that doesn't break the feature branch history like it does now [13:51] hatch: if you get a chance, I wonder if we could add a "how to sync with trunk" that's testing out using git rebase develop vs git merge/pull develop [13:51] hatch: and if that helps out [13:52] yeah...I'm just wondering why rebasing merges into your commits shows up in the diffs [13:52] that stuff 'should' already be in develop so why is it considering it 'new' [13:52] rick_h_: gave a +1 to the branch with that understanding. Onlty had small text suggestion [13:52] hatch: I think that's the diff between merge/pull/rebase. You can sync all three ways but they each act different and need to think through it [13:52] gary_poster: rgr, will update it. [13:53] I wonder what others do, I can't imagine that this isn't a asolved problem [13:53] people can't have a ton of broken commits in their trunk [13:53] ....well....shouldn't :) [13:54] gary_poster did you see that your font branch failed CI? [13:55] hatch, yeah thanks. Weird: it failed on IE in sandbox.PyJujuAPI tests! [13:55] No idea why. [13:55] ok that's odd [13:55] Want to try and dupe locally [13:56] there is a transiet error that happens in CI very rarely [13:56] oh! was wondering about that [13:56] gary_poster: if it's a really odd error I'd try to run it again [13:56] * rick_h_ goes to find the branch/build [13:57] https://github.com/juju/juju-gui/pull/101 [13:58] rick_h_: ^^^ is there a way to trigger a build without pushing another branch? [14:00] delete the message from CI [14:00] the 'status: merge request accepted' one [14:00] then it'll re-run [14:00] hatch, no this is the initial run [14:01] oh woops, sorry no idea [14:03] gary_poster: starting the process to release the GUI charm if you agree [14:04] frankban: +1 thank you [14:12] gary_poster: yes, got pulled away https://github.com/juju/juju-gui/blob/develop/docs/continuous-integration.rst#manually-running-a-build [14:13] perfect thanks rick_h_ [14:26] gary_poster: so http://ci.jujugui.org:8080/job/juju-gui/327/ looks like it went ok? [14:26] not sure why it didn't trigger a pass in github [14:27] cool, and awesome! thanks rick_h_. Tweaking branch now. Gives me rebase practice. :-) [14:28] gary_poster: cool [14:42] gary_poster was the test failure the long line? [14:42] or was that just a driveby [14:42] hatch, no, that was a driveby [14:43] hatch, the next test run passed without changes [14:43] oh :) [14:43] yea, it's a really odd and rare failure. I guess I should file a bug on it. Only hit it a couple of times [14:43] * hatch sings blame rick_h_ to the tune of 'Blame Canada' from South Park [14:43] but it does happen [14:43] lol [14:43] :P [14:43] I don't think rick_h_ can take any blame for those tests [14:44] maybe not, but it can be assigned [14:44] :P [14:44] hatch: I just got out of a meeting with Mark S and he wants you to build Jaas by yourself by the end of the month. GO! :P [14:44] :-) [14:44] heh [14:44] rick_h_ lol, wouldn't be the craziest request I've gotten haha [14:44] We won't tell you what it is, but if you get it wrong, you're fired ;-) [14:45] hahaha [14:45] that's pretty close to some of the requests I've received [14:45] one month of paid job-hunting; sounds like a good deal to me a [14:45] "can you build us an app for our startup....but we can't tell you what we do now..." [14:45] heh [14:46] benji lol [14:46] gary_poster: AWS expenses incoming [14:46] cool benji, I'll catch 'em [14:47] juju-core can be up/downgraded nicely [14:47] done. [14:47] at least it appears to not be barfing all over the place [14:48] seems to be considerably slower though.... [14:50] I just enjoy using the GUI when using Juju....guess that means we did a good job :) [14:51] :-) [14:51] +1 [14:53] you know... [14:53] if you look at the jenkins test console (http://ci.jujugui.org:8080/job/juju-gui/331/console)... [14:53] a *lot* of the time is spent on 304 requests [14:54] a *whole bunch* [14:55] you bet [14:55] rick_h_ and I have both been wanting to write a cache layer for those json requests [14:55] cache headers would be dagerous [14:55] it's no just json fwiw [14:55] svg and yaml too [14:55] I was thinking something in the app [14:55] gary_poster: right, but all of those are through the "loadxxx" helper that needs to just send back the data [14:56] yeah that [14:56] so the app itself would cache? [14:56] in a util? [14:56] so it's just a matter of faking the cache in the test util helper [14:56] no the app, it's in the tests only [14:56] 'just' famous last words lol [14:56] that might be an 80/20, yeah [14:56] hatch: :P come on. It's easy. You could do it in an hour. [14:57] heh [14:57] rick_h_ lol shush [14:57] * rick_h_ downloads hatch's ghost zip [14:57] ok hatch or someone else in jujugui, https://github.com/juju/juju-gui/pull/104 has passing tests and is ready for review (hopefully easy) and qa (more annoying) [14:58] * hatch needs someone to actually use the ghost charm so I can get motivated to keep working on it [14:58] do demos count? ;-) [14:58] haha, well it works for demos now. 'lowest viable product' :P [14:58] :-) [15:01] hatch: Failed to load resource: the server responded with a status of 405 (Method Not Allowed) [15:01] :( [15:01] rick_h_ are you using the latest charm and juju 1.17.1+ [15:01] 1.17.3-trusty-amd64 [15:01] cs:precise/juju-gui-82 [15:02] I got juju from trunk with the go get juju... [15:02] and I changed the juju-gui-source to the develop branch [15:02] in the charm [15:03] hmm something is messed up with charmworld.....juju-gui latest is revno 83, but it's deploying 82 [15:04] hatch: cs:precise/juju-gui-82 is revno 83 [15:04] ohh ok, so then it 'should' be working [15:04] frankban I thought the numbers on the end matched the revno [15:04] :) [15:05] rick_h_ can you view the guiserver logs in the charm? [15:05] hatch: looking [15:05] hatch: I used to know the meaning of the number after the last dash, but I keep forgetting that and I ended up just considering it an obscure auto-incrementing mystical number [15:06] haha sounds good [15:07] hatch: which log? nothing in /var/log/juju/juju-gui.log [15:08] guiserver.log [15:08] it's in... [15:08] /var/log/upstart [15:08] ah right uin upstart [15:08] yeah this is the actual 'server' logs [15:08] [W 140204 15:07:13 web:1635] 405 POST /juju-core/charms?series=precise (41.164.30.187) 7.48ms [15:09] that's it hey? [15:09] frankban any ideas? [15:09] yep [15:09] all I get in there [15:10] frankban 83 supports the local charm stuff right? [15:12] gary_poster: bac comingsoon has a merge conflict issue [15:12] rick_h_: ok [15:12] jujugui: https://jujucharms.com/sidebar/search/bundle/~abentley/wiki-bundle/1/wiki/?text=bundle#bws-code is an official bundle that we cannot deploy. since the bundle includes local charms (those with "branch:") the fake backend fails. this is related to bug 1276107 , but I didn't know those kind of bundles were exposed in the GUI [15:12] <_mup_> Bug #1276107: gui fails to deploy a bundle due to "Invalid charm id: undefined" [15:12] rick_h_: will check it out [15:12] hatch: revno 83 does not [15:12] rick_h_ doesn't look like the 83 supports it [15:12] thanks bac [15:12] sorry [15:12] frankban: so that is an old old bundle that sohuld be deprecated and removed [15:12] https://code.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk [15:13] frankban: as we update the rules and proof we don't go back and clear old things out [15:13] frankban: maybe we should do that [15:13] hatch: I am in the middle of the charm release. hopefully the new charm with putcharm enabled will be released in 30 mins [15:13] hatch: oh sorry, thought it as there [15:13] frankban: ah ok cool. I'll retry setting up the demo later tonight then [15:13] rick_h_: was using local charms for demo [15:13] thanks for the heads up [15:14] yea, it's friday. I got the juju-core part working so that's a good bit. If the charm gets updated then should be all ready for the demo well in time [15:14] rick_h_: I'll ping everyone once the charm is released [15:14] frankban: ty [15:14] rick_h_: re frankban's comment about the failing bundle, any ideas how that made it through proof? [15:14] gary_poster: it was pre-proof checking things [15:14] rick_h_: I thought we had a re-import though [15:15] it's one of the first bundles we ever put in to test/prove charmworld could test them. [15:15] I think it goes into an error state, and we don't repull it but I don't think we clear it out. Am I mistaken on that bac ? [15:15] gary_poster: in theory we're treating it like a bad revision if I recall correctly. [15:16] rick_h_: unfortunately that's also the first bundle result if you search for "bundle" on the side bar [15:16] :-( [15:16] frankban: hah, ok. We should yank it. Maybe benji can try out his charm remover on the bundle? [15:16] yeah was thinking the same thing [15:17] hulk smash! [15:17] rick_h_: comingsoon should be happier. [15:17] bac: thanks [15:18] * rick_h_ puts a note to look at adding a monitoring thing on our azure account. See if we can get a notice if it fails to load [15:18] jujugui: remember to QA on coming soon if you muck with config.js (but we always forget) [15:18] I'm happy to delete the branch if you want. [15:19] ah I have one of those comingsoon config fun things coming up too, maybe [15:20] gary_poster: do more better! [15:20] thanks abentley. That sounds like a good idea to me. We still need to delete it in charmworld. [15:20] :-) [15:21] hatch you looking at https://github.com/juju/juju-gui/pull/104 or planning to, or should I beg someone else? [15:22] gary_poster: btw, the URL after "bzr branch" is a bit weird. You never need /files after a Launchpad branch URL. [15:31] thanks abentley, yes. Fixed in trunk (http://comingsoon.jujucharms.com/sidebar/search/bundle/~abentley/wiki-bundle/1/wiki/?text=bundle#code) and even in recent GUI releases. jujucharms hasn't had an update because we are blocked on switching to juju core. [15:31] gary_poster: cool. [15:32] http://comingsoon.jujucharms.com/~dweaver/complex-webapp-and-management-bundle/8/complex-webapp/ could look better :-/ [15:32] sorry [15:32] correct link: [15:32] http://comingsoon.jujucharms.com/sidebar/bundle/~dweaver/complex-webapp-and-management-bundle/8/complex-webapp/ [15:34] gary_poster yeah I'll be looking at it [15:34] thank you [15:34] my env is a little messed up right now because of testing for old juju versions and the like [15:34] gotcha [15:39] jujugui do we know the version of juju in the GUI now? I remember hearing some discussion on the matter but wasn't sure the outcome [15:40] hatch: no we don't [15:40] ooooo kaaaayyyyyy [15:40] little unfortunate [15:41] hatch: what do you need that for? [15:41] frankban when the user tries to upload a charm and it's not supported I was going to say "Your version of Juju ({version}) does not support local charm uploads, please use at least 1.18.0" [15:41] so I'll just drop out their version for now [15:43] hatch: ack not too bad [15:44] nope [15:50] jujugui call in 10 [15:52] hatch: I can't reproduce bug 1271986 [15:52] <_mup_> Bug #1271986: Destroying service leaves inspector open [15:52] benji looking [15:52] benji it was intermittent [15:52] maybe try a couple times? [15:53] hatch: I did. I'll try some more. How long were you letting it be in pending before destroying it? [15:53] benji 30s or so I think [15:53] k [15:53] frankban the error returned from the charm when trying to use local charm upload is: [15:54] Internal server error: [15:54] error fetching data from https://10.0.3.1:17070/charms?series=precise: HTTP 599: Unknown [15:54] do we want to expose that url? [15:55] hatch: is this the error with old juju-core versions? [15:55] frankban yes, the ~juju-gui charm and juju 1.16.x [15:56] it should really be returning a 405 imho instead of a 500 [15:56] shall I file a bug on the charm? [15:58] jujugui call in 1? 2? [15:58] jujugui cvall in 2 [15:59] * gary_poster has a broken clock on Ubuntu :-P [15:59] ha, i beat you and spelled it right! :) [15:59] heh [16:28] * gary_poster tries restarting Ubuntu after a software update to see if he gets his clock & cal back === gary_poster is now known as gary_poster|away === gary_poster|away is now known as gary_poster [16:31] Makyo: fwiw, software update + reboot = clock. yay! [16:32] 'course, now chrome crashes :-/ [16:36] price of using beta software I suppose :( [16:37] gary_poster, rick_h_: gui sandbox mode is broken (my putcharm branch introduced an error in the GUI server when here is no API URL). made an urgent card and starting to work on the (easy) fix. this will delay the charm release to tomorrow, is that a problem? (anyway: yay functional tests!) [16:37] frankban: :-) no problem IMO [16:38] cool [16:46] jujugui lf a review and qa https://github.com/juju/juju-gui/pull/105 plz and thanks [16:47] hatch, on it [16:48] thanks [16:48] and now I can do the qa on your branch [17:02] jujugui can someone on Ubuntu check if the drag and drop works in Firefox? [17:02] It's not working in OSX Firefox [17:04] hatch: drag'n'drop of what? [17:04] the charms/bundles [17:04] local charms? [17:04] sorry [17:04] from the browser [17:04] hatch: oh, from the sidebar [17:05] yeah [17:05] hatch, qa bad. I'm using 1.16.5-saucy-amd64 . I have two problems. First, e.target.responseText is simply 'badMessage'. You try to parse that as JSON (line 152 of local-charm-import-helpers) and the JSON parser is unhappy and falls over. Second, even if that were fixed, the server responds with a status of 405 (Method Not Allowed) not 500 or 599 or anything else. That second one wuld be solved easily by [17:05] reporting an error when the status >= 400, as I suggested already in the review. [17:05] gary_poster are you using the ~juju-gui charm? [17:05] hatch yes [17:05] trunk [17:05] weird...it returns 500 for me [17:05] hmm [17:06] hatch: dragging charms from the jujucharms.com sidebar works for me using ff [17:06] ok must be OSX only FF [17:06] :-/ [17:07] hatch do you want any more info from me on the qa? hangout? [17:07] whatever helps [17:08] well no I'm going to have to switch back and deploy a new env and give it another go [17:08] ok [17:09] hatch: I confirm charms drag and drop is broken on OSX Firefox [17:09] gary_poster juju-gui-103 is the charm that's deployed? [17:10] hatch, no, charm trunk--the charm Francesco is releasing now. [17:11] hmm I thought that's what I was running...ok tearing down and starting a new env [17:12] hatch: trunk is cs:~juju-gui/precise/juju-gui-151 [17:12] oh shoot I'm working on frankban's branch [17:12] .... [17:13] WELL THEN! [17:13] :-) [17:13] Yay QA? :-) [17:13] well it takes considerably longer to be able to test than to actually write the code hah [17:14] hatch, pretty fast if you use a local charm, a local environment, and a release created via `BRANCH_IS_GOOD=1 make distfile`, as I keep saying [17:14] oh right, but I had already spun up another env on 1.17.2 [17:15] bzr may do rebase nicely but man does it not do lightweight checkouts well [17:38] * gary_poster lunches [17:38] gary_poster I can't get anything other than a 500 :/ [17:39] juju status shows juju-gui-104 charm as deployed [17:39] which was a fresh trunk checkout [17:41] bzr revno is 159 [17:42] gary_poster: when you have time could you please take a look at https://codereview.appspot.com/57690051 ? no rush and thanks! [17:52] hatch, gary_poster re: huw's branch. I rebased and pushed to a branch on my fork. Want me to use the merge tool (create a PR with my branch, immediately :shipit:) or manually merge huw's branch into develop (will mean having a non-jujugui user in merge history) [17:57] ^^^ + anyone else who cares (jujugui) [17:58] Makyo I'd probably prefer to use the CI system [17:58] Makyo: doing the latter will give huw credit. i'd go that route, even if he isn't in jujugui [17:58] so, flip a coin! [17:58] haha [17:59] bac, I think it'll give me credit, actually, since the push will come from my user. [17:59] Makyo: then go CI [17:59] Though the rebased commit is in his name. [17:59] Okay. [17:59] Bit of email spam coming up, then. Disregard! [18:14] gary_poster here is the output from the guiserver.log file when I try and upload a charm https://gist.github.com/hatched/69720b483da125bf951c does yours look similar but with a 405? [18:18] hatch, [18:18] [W 140204 16:59:11 web:1635] 405 POST /juju-core/charms?series=precise (10.0.3.1 [18:18] ) 97.51ms [18:18] that's the error you get with an old version of the charm....are you SUUUUUUURE you're not using an old one? :) [18:19] hatch, [18:19] gary@gud:~/dev/guicharm/trunk$ bzr revno [18:19] 159 [18:19] well now I'm right confused [18:19] and juju status shows juju-gui-104? [18:19] and from bzr info: [18:19] parent branch: bzr+ssh://bazaar.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk/ [18:20] from juju status: [18:20] charm: local:precise/juju-gui-104 [18:20] so somehow we are running the same code but getting two different responses from the server [18:21] hmm [18:21] 1.16.5-precise-amd64 [18:21] yup we are running all of the same code [18:21] and getting two different results [18:21] no we are not [18:21] 1.16.5-saucy-amd64 [18:21] should not make a diff [18:22] but that's the only one we see so far [18:22] see the issue with your log is that it doesn't show that it's trying to make a request to Juju [18:22] if you use an old charm that's the same response [18:22] * hatch puts thinking cap on [18:23] I can redo everything with you on screenshare? [18:23] well it's not like I don't believe you haha [18:24] sure, but maybe I'm forgetting something or you will think of something else to check [18:24] hatch I have this as first line of my guiserver.log: [18:24] [I 140204 16:56:51 manage:144] starting Juju GUI server v0.3.0 [18:24] 0.3.0 old? [18:25] yeah we can give it a try [18:25] umm checking mine [18:25] ^[[32m[I 140204 17:34:06 manage:144]^[[0;10m starting Juju GUI server v0.3.0 [18:25] :-/ [18:25] so same [18:26] hatch did you deploy with make deploy? [18:27] I did it the old fashioned way now to make sure it's all good [18:27] https://plus.google.com/hangouts/_/72cpibkk7s99ntjs8svf322nk4?authuser=1&hl=en [18:27] ^ gary_poster [18:50] this doesn't really effect us much but there has been a huge improvement to the loaders resolve speed https://github.com/yui/yui3/pull/1606 [18:51] so, startup time? [18:51] nah we don't use the loader at all in our client side app [18:51] ah right [18:51] the only thing this could speed up is the resolving of the 'make' step [18:51] the funny thing is that the loader totally breaks the speedy improvements [18:52] :) [18:52] why does it break the speedy improvements? [18:53] because it rolls everything up into only a few requests whereas with speedy those requests should be determined by the server and it's the servers job to send the data down the available pipes [18:53] so instead of only 3 requests, speedy could open 8 [18:53] and actually make it faster [18:54] the issue of course is that someone needs to write a speedy capable yui server [18:54] ah [18:54] I see [18:55] I don't totally understand all of speedy but in theory it should make the web way faster for web sites [19:01] gary_poster I totally blew everything away, and I still get a 500 [19:01] *sigh* haha [19:02] hatch try a saucy vm? :-) [19:03] the issue now is trying to determine what the error message should say [19:04] if status == 405 or 500: [19:04] hah [19:04] >= 400! [19:04] IMO [19:04] right but then I have to put a try catch around the json parse [19:04] and I don't like those.....for no reason [19:04] :-) [19:05] I'm spinning up an instance to qa your branch btw [19:05] cool ty [19:06] so far all osx browsers are good, just trying with ie now [19:11] cool [19:39] bac, juju-gui trying to do comingsoon surgery [19:39] in prep for my config change coming down the pike [19:39] and while I'm at it [19:39] gary_poster: ok [19:40] juju-gui you may want to make clean next time after you `git pull juju develop` [19:40] gary_poster: the branch we're using is now juju-gui (again) [19:40] bac you mean /opt/uistage/juju-gui? [19:40] gary_poster: you may want to get rid of the others since they are no long needed [19:40] gary_poster: yes [19:40] ok thanks [19:40] git stash is not working [19:40] going to try and be more manual about it [19:40]