[00:13] it opens [00:13] you can't open it? [00:13] ^ huwshimi [00:19] hatch: I had to add a charm first [02:54] huwshimi: so how's it going? Are you wroking now? I have no idea what your hours are :) [03:15] hatch: Hey, yeah I start my day at the end of yours (well, depending on what hours you work :)) [03:15] i'm UTC-6 [03:16] hatch: I'm UTC+10 [03:16] 16h difference? [03:17] crazy [12:45] matsubara, hey! how goes tarmac? [12:46] hey hazmat, could you make ~juju-gui a member of https://launchpad.net/~charming-devs, and/or whatever else is necessary so that I can be an editor and approver of https://blueprints.launchpad.net/charmworld/+spec/s-cloud-jujucharms-site-authors-api (and add my own blueprints there) please? [12:47] gary_poster, hey I think it's ready to switch on. I'd like to make a test run. do you have a mp ready so I can test? [12:47] matsubara, awesome! lemme see [12:49] matsubara, benji's mp looks like it will be ready Real Soon Now [12:49] yeah benji? [12:49] * benji frantically hits ctrl-c [12:49] I was submitting it. [12:49] lol [12:50] matsubara, https://code.launchpad.net/~benji/juju-gui/go-sandbox/+merge/169036 if benji was able to stop the submission in time :-) [12:50] https://code.launchpad.net/~benji/juju-gui/go-sandbox/+merge/169036 [12:50] yep [12:50] cool! [12:50] thank goodness for long test runs [12:50] haha [12:50] thanks benji. have at it with our thanks matsubara :-) [12:51] The best thing I've read this week: "On FedEx vehicle for delivery" [12:51] heh [12:51] I never looked at that video [12:51] I'll go look [12:53] heh, wow [12:55] very nice benji :-) [12:56] I'm very excited. :) [13:01] jcsackett: ping, got a sec? [13:02] morning sinzui. If you have some time in the next hour to talk blueprints, I'd like to run some things past you and ask some questions [13:02] gary_poster, I do after 10. [13:03] sinzui, you mean 10 minutes or 10AM? [13:03] 10AM [13:04] sinzui, ack. I'm booked after 10 until the afternoon, and was hoping to catch up with you in the morning. If I have a free moment I'll check with you, and otherwise will try you in the afternoon. thanks [13:04] gary_poster, benji: that MP is still in needs review and no commit message set [13:05] oh, I guess that's something the new lpsubmit will do; I'll hand-edit the MP now [13:05] thanks benji [13:05] (and yes, it does that) [13:06] matsubara: you should be good to go [13:09] benji, looks like it picked the MP while you're still editing the commit message but had changed the status to approved [13:09] it's a good sign that tarmac is working heh [13:09] heh [13:09] :-) [13:10] yeah, I guess I should have done that in the other order [13:11] I'm re-running it. Tarmac picked it up and should start the jenkins job soon [13:15] gary_poster: we can move our call up if it helps [13:15] gary_poster, benji: voting criteria not met. A member of juju-gui hackers needs to approve the MP (I claimed the review and approved it and am re-running the tests) [13:16] matsubara: I approved it, is self-approval not allowed? [13:16] teknico, thank you, great idea. maybe in 14? sinzui, then we'd be able to talk at 10 [13:17] benji, yes, it's allowed. the thing tarmac complained is that there were no review approvals [13:17] gary_poster: deal [13:17] ah [13:17] thanks teknico [13:17] matsubara, we need >= 0 [13:17] benji, it needs the reviewer approval and the global status approved [13:17] ah ok [13:17] I'll change that [13:17] thanks [13:18] otherwise the rietveld workflow doesn't work, unfortunately [13:18] gary_poster, well I guess then it's just a matter of disabling the voting plugin from tarmac, right? [13:19] gary_poster: I thought abentley's tool would copy the LGTM as 'approved' and would make that work [13:19] since once there's a MP on LP, means it's approved from the rietveld side [13:19] matsubara, makes sense. we might want it later but not now [13:19] cool [13:19] rick_h: No, my tool ignores reitveldt entirely, since all the necessary info is on Launchpad. [13:19] abentley: ok, so it doesn't make the LGTM comments copied into LP a "approve" state? [13:20] rick_h: No. It's a user script. You'd have to be an admin to change someone else's vote. [13:20] abentley: ah, nvm then. oh well [13:21] gary_poster, benji: http://10.189.74.2:8080/view/CE/job/jujugui-merger-trunk/7/console [13:21] rick_h, abentley's script looks at reitveld LGTM and adds that to the commit message [13:21] it's running the tests, could you look at the output and see if looks sane? [13:21] matsubara, so far so good! [13:21] gary_poster: gotcha, I misunderstood. I thought it would change the type of comment to an approval as well [13:22] it wouldn't be too hard to make it do so. All rietveld does is look for the string "LGTM" [13:23] benji, per Aaron's comment, the problem there is that the script is running as a user [13:23] benji: It wouldn't be hard to impersonate someone else on Launchpad and change their vote? [13:23] rt [13:23] ah, foiled by security [13:23] matsubara, where is the merge of benji's branch in there? [13:25] gary_poster, take a look at: http://10.189.74.2:8080/view/CE/job/jujugui-merger-trunk/configure I had to change slightly the command so tarmac can work. [13:26] gary_poster, tarmac merges benji's branch on /tmp/tmpOz9IkX/ then the builder machine copies that dir over and runs the tests on top of it. [13:27] gary_poster, one thing though, when jenkins run: bin/test-charm --origin $JUJU_BRANCH --charm $JUJU_CHARM, what does the --origin mean in that context? [13:28] orangesquad: Could you please review https://code.launchpad.net/~abentley/charmworld/no-docs/+merge/169202 ? [13:28] abentley: looking [13:30] benji, any chance you could help matsubara on the above? I need to do some other call-y bits, and I know you knew a previous incarnation of test-charm :-) [13:30] benji, hatch will also know where bodies are buried when he is around [13:30] * benji looks [13:31] let me get a diff of the changes, it'll be easier [13:33] matsubara: "origin" is where to get the source code [13:33] benji, https://pastebin.canonical.com/92720/ [13:33] err [13:33] clearly pasted the wrong thing [13:34] and I don't have my phone on me to log into that thing anyway [13:34] * benji goes to find his phone. [13:34] https://pastebin.canonical.com/92721/ [13:35] benji, http://pastebin.ubuntu.com/5761464/ [13:38] thanks matsubara. what am I looking at? [13:43] benji, so these are the changes to make tarmac work. Tarmac creates a tmp dir with lp:juju-gui + the approved MP branch. The jenkins jobs then copies that tmp dir from tarmac machine and runs the test on top of it. I think what's missing is tarmac to send $JUJU_BRANCH to the job and use that as the --origin [13:45] matsubara: cool; I still don't quite understand what (if anything) you're asking me to do though :) [13:49] orangesquad, gary_poster, all the charms are being re-indexed...search has not charms at this time [13:50] I expect them to be back in 15 minutes [13:50] sinzui: Hmm. Shouldn't work that way. The new index is supposed to become active after the copy is complete. [13:50] abentley, isn't this the stale queue issue with branch_deleted? [13:50] sinzui: Are we talking about reindexing or ingest? [13:51] abentley, ingest really [13:51] sinzui: Oh, then yes we probably hit the same branch_deleted issue. [13:52] I see charms re-appearing now [13:54] I see 75% of the charms now [13:55] morning [13:56] gary_poster: benji no bodies in CI , it's stable as a rock... [13:56] bahahaha [13:56] hatch, :-) [13:56] * benji doesn't understand but guesses that is a good thing. [13:56] sinzui, is this something that might need to happen again? [13:57] gary_poster: last night I fixed the jumping service issue, waiting for Makyo to tell me why it's doing what it's doing (hoping he knows) [13:57] Yoooou raaaaaang? [13:57] lol! [13:57] oh haha, I thought you didn't start for another hour [13:58] hatch, great! huwshimi has lp:~huwshimi/juju-gui/header-design [13:58] based on your branch [13:58] I've been trying to catch a few minutes to look at it [13:58] Nah, 8 my time. [13:58] So 2 minutes. Let me make another coffee. [13:58] gary_poster, yes....We think we want to empty the ingest queue after each deploy of code to ensure the ingest/indexing process is knows exactly what it will find in the queue [13:58] Makyo: oh so we must be on the same tz right now [13:59] sinzui, ah ok. this strikes me as a significant usability issue if it means that no-one can search for charms from jujucharms.com and the GUI everytime we roll out [13:59] gary_poster: cool, am I supposed to merge it into my branch? [13:59] gary_poster, It dosen't happen every time, but I think the next time we change the definition of charm data, we must ensure there is a mechanism to clear the queue [14:00] hatch, not supposed to. Would be nice to have it land today. Separately probably makes sense [14:00] hatch, you or I can try to get it reviewed and landed once your branch is in [14:00] gary_poster, I take the loss of search as down-time and we don't ever want to be down more than a few seconds [14:00] alrighty [14:00] * hatch grabs coffee [14:01] sinzui, k. you available now for call? can talk about this also then [14:01] 5 minutes? I need to find coffee [14:01] cool sinzui [14:02] benji, hatch, matsubara goal of conversation with matsubara is to review what he has set up with tarmac so we can sanity check it. Also matsubara had one specific question: [14:02] matsubara> gary_poster, one thing though, when jenkins run: bin/test-charm --origin $JUJU_BRANCH --charm $JUJU_CHARM, what does the --origin mean in that context? [14:03] matsubara: gary_poster it's the origin to pull the gui source from [14:03] hatch, so does that mean the branch that is being tested? [14:03] correct [14:04] I am afraid that the config that matsubara has might still be testing the trunk, rather than the merged branch from tarmac [14:04] so that's what I'd review [14:04] in particular [14:04] see lib/deploy_charm_for_testing.py:188 [14:06] gary_poster, hatch, I think I have enough to continue. I'll have to change the jenkins tarmac plugin to send the $JUJU_BRANCH as well. [14:06] while bin/test-charm is being run from trunk + mp's approved branch [14:07] gary_poster, ready [14:10] Alright, hatch. What's up? [14:10] cool matsubara thanks [14:10] Makyo: ok in onCharmDeployClicked in views/charm-panel.js there is a call to env.update_annotations() [14:11] in that call it updates the gui-x and gui-y which work as planned [14:11] then in the callback it removes the x and y attributes from the ghost [14:11] it's this removal which is causing the jumping in my branch and not in trunk [14:11] it appears to have no side effect if I comment those out [14:12] so the issue is that when, in the following lines, it setAttrs() there is no x, y so it places it in the middle [14:15] Alright, I see what you mean. I think that's left over from there potentially not being annotations to set, which changed when we added the branch for new service placement. [14:15] I think those are safe to remove, now. [14:16] excellent - I really dont know why it breaks in my branch and not in trunk however [14:16] I just found the sollution, around 1am I called it quits hah [14:17] Yeah. I don't necessarily know why, either, but I don't see a problem with the solution. [14:17] Would take some digging. Worth QAing extra. [14:18] cool - will work on cleaning up the mess I made of this branch tracking that down then land this [14:18] thanks for the sanity check [14:23] Oh, hey, neat: http://www.google.com/trends/hottrends/visualize?nrow=15&ncol=15 [14:46] adeuring, Let's consider https://bugs.launchpad.net/charmworld/+bug/1190627 as a part of the feature you are working on. We don't want charms to disappear temporarily. In this case, the unavailable service is our queue because it contains stale data [14:46] <_mup_> Bug #1190627: Charms can disappear when code is deployed with a stale queue [14:46] sinzui: right [14:49] Makyo: what am I looking at? [14:49] Search trends in real time. [14:50] ohh - I thought it was Google making fun of Windows 8 tiles [14:50] lol [14:50] Hah :D [14:52] ohhh Makyo one other thing [14:52] Shoot. [14:52] trunk is broken wrt service layout [14:52] on rapi large, take note of the layout [14:52] add a service, wait for it to become 'alive' [14:52] then refresh [14:52] your other services will have moved [14:53] sometimes only a little, sometimes a lot depending on their orientation [14:53] hatch, that's by design because default layout doesn't imply annotations have been set, nor does it set them. They are set when a new service is added, though. [14:53] ok so if I move all services then that shouldn't happen? [14:55] Correct. In reality, it will likely be one of two cases: the IS case, in which annotations will never be set because the GUI is effectively read-only, and the deploying case, where annotations will always be set because they were deployed from the GUI. The intermediate case you're dealing with is possible, but the default layout encourages dragging; if we come up with a more intelligent default layout scheme, we can start setting annotati [14:55] ons by default. [14:56] sinzui: pre-imp re: 1176901 ? [14:56] kewl I see that now, thanks for clearing that up [14:56] abentley, in a few minutes, just finishing a meeting [15:02] abentley, I am ready [15:09] matsubara: are you still working with my branch or should I land it the old-fashioned way? [15:15] benji, sorry, running tarmac again. If it doesn't work this time, I'll re-enable the old jenkins job and you can land in the old way [15:15] cool, thanks [15:33] sinzui: We could avoid spamming the store in the case of multiple jobs for a charm using rate-limiting. We could store the last-updated-from-store time, and skip retrieving that data if we used the store too recently. [15:35] orangesquad: do you already have a bug for a request to https://manage.jujucharms.com/api/2/charm/login when logging out of the GUI ? [15:35] hatch: not that I know of. Can you file something with instructions for duplicating? [15:36] definitely, do the bugs just go on juju-gui? Do I tag it with anything for you guys? [15:36] hatch: yes, tag it charmbrowser [15:36] cando! [15:36] hatch: though I'm confused, is this on manage.jujucharms.com? [15:36] * rick_h is confused, what logout did you hit to get an api url? [15:36] on trunk running rapi [15:36] clicked the logout button [15:36] hatch: k, yea then tag charmbrowser under the juju-gui I guess [15:37] actually it does it on sandbox as well [15:37] ok making ticket [15:38] hey it looks like the tarmac is working [15:38] matsubara: any way we can get the codereview link in the comment like before? [15:39] nice: "Status: Approved => Merged" [15:40] hatch, what do you mean? [15:40] matsubara: https://code.launchpad.net/~juju-gui/juju-gui/trunk see 728 vs 727 [15:40] hatch: right now the commit message is hand-rafted [15:40] it's not a huge deal, I have just found myself using it before [15:40] or "crafted" even [15:41] * benji invents the new sport of "hand rafting"; very dangerous. [15:41] in other words, I didn't copy that bit into the text box [15:45] benji: well I think it was inserted into there by something automatically [15:46] I like having that and the reviewers in there so when something breaks you know who to talk to and any review comments easily at hand [15:46] hatch: lbox submit does it, but since I wasn't using lbox to land the MP, I had to do it [15:46] ohh ok so it's something we can add back in at a later time [15:46] ? [15:46] right, I assume lpsubmit will do the same thing [15:48] rick_h: here you go https://bugs.launchpad.net/juju-gui/+bug/1190653 [15:48] <_mup_> Bug #1190653: Clicking logout makes request to manage.jujucharms.com

[15:48] benji: ahh cool [15:48] hatch: thanks, adding to the board [15:49] it's a pretty odd issue [15:52] jujugui call in 8 [15:52] hatch: you can look up a merge proposal with lp-find-proposal, e.g. bzr lp-find-proposal -r 728:lp:~juju-gui/juju-gui/trunk [15:52] kanban now [15:54] abentley: lol I can't even remember the proper bzr diff syntax half the time I'll definitely never remember that ;) [15:54] hatch: If you're in a trunk branch, lp-find-proposal -r 728 will work. [15:55] oh that I can remember :) [15:55] hatch: In fact, after you run log, any revno you see will work as long as you don't switch branches. [15:55] bzr has much saner defaults than git I find but I have no idea why I can't remember the syntax [15:58] jujgui call in 2 [15:59] jujugui ^^ :-) [15:59] heh thanks [16:03] matsubara, is tarmac ready to go for us, then? [16:05] luca__, hey. any news on google docs form and user form link design? [16:05] gary_poster: it's in progress, I imagine It'll be finished tomorrow [16:06] great thanks luca__ ! [16:06] gary_poster: no problem :) [16:06] gary_poster, nope. it can land stuff but still needs to be modified to send the JUJU_BRANCH [16:06] ok thanks matsubara let us know [16:06] gary_poster, I'll re-enable the old job for now and let you know when I can test again [16:06] thanks :-) [16:14] gary_poster: sent to juju-gui-peeps (I hope that is still active) [16:14] it is thanks benji [16:15] I got it [16:15] thanks [16:15] gary_poster: the remove-charmsearch branch is re-proposing now [16:17] hatch, cool. you need re-review or re-qa [16:17] ? [16:18] re-review probably isn't necessary but feel free to take a peek at the changes https://codereview.appspot.com/10241043 but I would like a fairly indepth qa if possible :) [16:18] heh [16:19] Haswell, 16GB ram, SSD mini pc :) http://www.engadget.com/2013/06/12/asus-vivopc-specs/ [16:20] orangesquad hatch review help please? short/sweet in the end https://codereview.appspot.com/10246044/ [16:20] on it [16:21] done [16:22] hatch: ty much sir [16:26] rick_h, hatch, code looks good. hatch did you do qa on rick's branch? if so will lgtm myself [16:26] gary_poster: not yet, [16:26] k [16:26] was just about to pull it down [16:26] thanks [16:27] hatch, looks like the panel config scroll is broken again. also fixed in rick's branch? [16:27] gary_poster: no, actually now that I look on a charm with enough config that's not fixed here [16:28] darn [16:28] can do it separately [16:28] but needs to be done urgently also [16:28] huw's changes make the ui look awesome - a little...chrome heavy imho but awesome :) [16:28] is that something we broke or is that bootstrap related? [16:28] hatch, rick_h one of you look at that? [16:28] rick_h, not you I don't think [16:29] hatch agreed [16:29] gary_poster: ah ok. I'm going to look at the logout issue that's us. If hatch can follow up on the config panel that'd be great [16:29] on awesome and a bit chrome heavy [16:29] rick_h, +1 thx [16:29] gary_poster: I have that fixed in one of my proto branches, so I can dig that fix up in a followup [16:29] yay! [16:29] thanks [16:29] gary_poster: just qa'd ricks branch and it shows all of the config properties now [16:29] yay! [16:29] will just test to make sure it saves them [16:29] heh [16:30] hatch: heh, I just have to get your a model, not save it :P [16:30] the ;tooltips cover the inputs :/ [16:30] oh nm [16:30] screwup with my browser plugins [16:30] hatch: ok yea I'm not seeing that [16:30] hatch your branch is looking great so far--that change even fixed the jumpy bit [16:31] rick_h: +1 on a QA, gtg :) [16:31] gary_poster: yeah it's pretty awesome :) [16:31] hatch: gary_poster ty much for the reviews. Will hop into the logout next and see if I can't clean up our last little bits of trouble [16:32] great! [16:32] hatch, found another weird issue with logout but not related to your changes [16:32] and not as urgent [16:32] at least with sandbox if you create services, log out, and log in [16:33] then services don't show [16:33] but exist (you can't add services with same name) [16:33] oh yeah I thought ben and I fixed that [16:33] in fact, I know we did [16:33] *regression* [16:33] hatch, not your problem, so can make a card, but if you have another fix in your bag of tricks then yay [16:34] hatch your branch LGTM in qa and code [16:34] eggcelent [16:34] rick_h: I'm working on the card "loadFixture should be able to exclude/ignore hashes when it generates urls" [16:35] rick_h: I can't reproduce the problem, do you know how to make it show up? [16:35] teknico: move the test_service_view.js and test_service_config_view in test/index.html back up into the middle of the test suite [16:35] teknico: I moved them to the very end to work around the issue for the moment [16:36] teknico: if you still can't dupe let me know and we can hangout and I can shot you what's going on exactly [16:36] rick_h: thanks, I'll better dupe it by myself, I don't want to be shot ;-) [16:36] teknico: the actual error ends up showing up as something about invalid chars or something because it's trying to json parse something it can't. [16:37] bah, /shot/show [16:37] of course :-) [16:39] damnit rick_h you submitted at the same time I did and now I have to restart lol [16:40] bwuhahaha my computer is faster :-P [16:40] lol [16:41] I'm just glad that it was smart enough to reject the merge instead of just forcing it haha [16:42] that would have been a mess [16:42] how much conflict could there have been? [16:42] well it would have just been missing code without any reasoning as to why [16:43] I worked on a project that used some custom svn workflow that you would have to notify everyone you were committing so you didn't do that [16:43] rick_h: weird, if I place those two tests right before test_model_controller.js, then I have an error in the latter [16:43] that was irritating [16:44] rick_h: where were they placed exactly? [16:44] teknico: hmm, don't recall where they were. I think just alphabetically [16:44] jcsackett, gave you second LGTM on showIcon, with trivial/ignorable suggestion [16:45] teknico: https://code.launchpad.net/~rharding/juju-gui/trailing-slash-1189973/+merge/168803 [16:45] rick_h: right [16:47] ugh mosquito bite on my foot....the worst! [16:48] alllright merged [16:48] rick_h: ok, got it, thanks [16:49] teknico: yay! ...well not really [16:49] :-) [16:55] gary_poster: so huw's branch looks great, but the UX for the right panel does not match at all heh [16:56] gary_poster: oh, and when I add services/log out/in on sandbox, the services stay there on the (new) trunk [17:13] I expect you're on a call, gary_poster. If so, say nothing for 60 seconds. GO! [17:14] benji boo [17:14] heh [17:14] gary_poster: so, either this card was very easy or I misunderstood; guichat? [17:15] hatch: (A) I know. if you want to try a quick CSS to the old inspector you are welcome, but otherwise oh well, it's incremental, and I think we can have the new inspector no later than end of next week [17:16] (B) great! [17:16] dunno what I saw then [17:16] benji, ok joining [17:23] hatch: hi, I'm trying to recall/understand the motivation behind the "Propose download-cache style solution for our node files using existing machinery" card we created during last Friday's meeting. [17:23] hatch: I think you were one of the progenitors of it so I wanted to check with you about what problem(s) you were hoping would be addressed. [17:25] benji: well there are two things 1) npm can and does go down causing work on new branches to stop and 2) making 100 http requests takes a lot longer than if we could just cache/extract a single file [17:26] hatch: will you try something for me? apply this diff http://paste.ubuntu.com/5762093/ and do a "make clean-all" and then a "make" and you should get no HTTP requests [17:26] hatch, the jenkins failure is real and reasonable: the tests use the old load panel [17:27] benji: that originally started with me there. [17:27] if this were tarmac, your branch would have been kicked out. :-P so...looking at that for a sec... [17:27] rick_h: maybe you will test it out for me too then :) [17:28] benji: yep, peeking at the diff as well :) [17:28] don't blink or you'll miss it [17:28] yea, I see that [17:31] gary_poster: ok so that's a python test failure? Sorry I didn't even think of looking in the selenium tests [17:31] hatch no apologies needed. we are supposed to have tarmac for this [17:33] hatch, yeah, so we need to rewrite that deploy function. are you up for that, or would you prefer to call "Python!" and I'll ask benji to switch and/or pair with you? [17:34] this is deploy on 109 of test_charm_running.py? [17:35] ahh yes this needs to point to the charmbrowser now [17:35] 112 for me but yes (me does another pull) [17:35] still 112 for me :-) [17:35] I 'think' I can do this [17:35] :-) cool [17:35] is ther a way I can test it locally? [17:35] if you change your mind call for help [17:35] yes [17:36] hatch, open your hymnal to docs/continuous-integration.rst and read with me...as I try to remember the details. [17:37] lol, read that as "open your hy-yaml" and went wtf? [17:37] lol [17:37] I don't even know what a hymnal is [17:37] to google! [17:37] ohh [17:37] * rick_h is rolling on the floor [17:38] hym-nal [17:38] now I get it [17:38] :) [17:38] lol [17:38] ...so anyway... [17:38] haha [17:38] doesn't look like the CI docs contain instructions on running selenium locally [17:38] hatch, look for the section that begins here [17:38] Combining NO_DESTROY and APP_URL could help while debugging CI tests, and it [17:38] allows for running the suite multiple times using the same Juju environment. [17:38] A typical workflow follows:: [17:39] ohh yeah that part [17:39] but I still need EC2 for that [17:39] mm [17:39] I know about doing THAT much ;) [17:40] I assumed frankban didn't hammer on EC2 when fixing things and ran it locally somehow [17:40] well, one other thing to check, one sec [17:40] I could have been assuming incorrectly [17:42] hatch, yeah ec2. fwiw, http://irclogs.ubuntu.com/2013/06/11/%23juju-gui.html and look for "I suggest configuring the juju-gui-testing env with the ec2 provider" [17:43] yup already have that setup [17:43] ok to ec2 it is! [17:43] k [17:43]