[11:34] hi rogpeppe: when you have time, I need another approval for https://codereview.appspot.com/7947043/ [11:35] frankban: looking [11:35] rogpeppe: thanks [11:37] frankban: there was one little thought i had last night, and it seems i lost the comment somewhere [11:38] frankban: in annotator.insertOps, if you reverse the order of the operations, the code could become a little simpler looking [11:40] frankban: like this: http://paste.ubuntu.com/5649143/ [11:41] rogpeppe: I see. ok [11:48] rogpeppe: I'll make this change and then land the branch, sounds good? [11:48] frankban: i've just made one other final suggestion in the review [11:49] frankban: LGTM with both those changes made, thanks! [11:49] rogpeppe: cool, thanks [12:15] frankban, hi. are you available for a quick consultation on some CI/shelltoolbox topics? [12:16] gary_poster: sure [12:16] thanks frankban. no rush, guichat when you are available [12:25] gary_poster: hiya [12:26] gary_poster: do you know if anyone is currently working on adding more fields to the various allwatcher info types? [12:26] rogpeppe, benji if anyone [12:26] he will be the person to do it [12:27] rogpeppe: not at the moment, but soon [12:27] benji: ah - i've had a request from green for public address and status in unit info. if you're about to do it, i'll leave it to you though. [12:28] rogpeppe: I can do that, if gary_poster doesn't have any immediate plans for other things for me to work on [12:29] benji, I would take advantage of rogpeppe being willing to do some of the work we need :-) [12:29] lol [12:29] heh [12:30] benji: i'd be happy to do it. i could do all the other fields at the same time if you like - let me know what you need [12:30] we need what is used in the GUI, let me see if there is an easy to extract list [12:32] benji, my guess was in app/store/env/sandbox.js in _deltaWhitelist [12:32] it is at least a reasonable start [12:32] cool, looking [12:35] rogpeppe: here is a pretty good list of attributes: http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/app/store/env/sandbox.js#L213 [12:40] benji: thanks. the only immediate issue i see is machine.instance_state and machine.public_address [12:41] benji: because we don't currently have those available. [12:41] benji: except by talking directly to the environment [12:41] we'll take what we can get, for the time being :) [12:42] rogpeppe, agreed with benji, but I suspect we need to figure out how to get at least one of those. I'll do a quick search... [12:42] gary_poster: i have two possible solutions in mind [12:43] we definitely use public_address... [12:43] looknig for other [12:43] yup, we use instance_state too [12:43] gary_poster: could you use the public address from the units instead? [12:44] rogpeppe, if they are functionally equivalent then absolutely [12:44] gary_poster: yes, i think the PublicAddress in a unit is just what would be provided by the machine [12:44] rogpeppe that's perfect then [12:45] gary_poster: the instance state is a little harder, as it's something that needs to be polled from the provider [12:45] benji ^^ PublicAddress on units will require some tweaks. Could you note somewhere, publicly (card) or privately (personal task) [12:45] gary_poster: one solution involves putting the information in the state, and adding a jujud worker that polls for information from the provider. the other involves adding an API call to retrieve the info explicitly [12:45] gary_poster: dure [12:45] :-) [12:45] or "sure" even [12:46] gary_poster: i'm inclined towards the latter currently. something like MachineInfo(id string) struct{PublicAddress string; InstanceState string} [12:46] rogpeppe, that sounds workable. We only show that on one very deep detail page [12:47] rogpeppe, what would you expect the usual turn-around time on a response to that query to be? or is that a fair question? [12:47] gary_poster: that seems good then. and it's something that can be changed deliberately by an admin, so having manual control of refresh might be a good thing [12:47] gary_poster: card added [12:48] thank you benji [12:48] gary_poster: 680ms [12:48] np [12:48] gary_poster: more or less :-) [12:48] rogpeppe, lol ok UI'll take it [13:52] mornin [14:00] rogpeppe, hi :-) I need some more help with one last reset() function in api_test.go [14:01] teknico: i've got a call right now. will be with you in a short while. [14:01] rogpeppe, great, thanks === Makyo|out is now known as Makyo [14:01] I'll start writing as an attempt to optimize the pipeline :-) [14:02] I rewrote opClientServiceDestroy to attempt destroying a non-existent service, as you mentioned yesterday: http://pastebin.ubuntu.com/5649448/ [14:03] it works because TestOperationPerm ends up matching the error with "permission denied" (not sure how much the test is meaningful though) [14:03] however, I still have a problem with opClientDestroyRelation: opClientDestroyRelation [14:03] ehm, http://pastebin.ubuntu.com/5649442/ [14:03] benji: doing a review on your branch right now [14:04] cool, thanks hatch [14:04] as you can see, it has the usual problem of trying to destroy the relation that still exists [14:05] sorry, it tries to *add the relation that has not been destroyed yet [14:05] I tried rewriting it in the same guise as opClientServiceDestroy, attempting to destroy a non-existent relation [14:05] but the result is not as good: it works for some machines but not for others in the loop [14:07] that's the last reset() function you asked me to add, then I'll be able to propose this branch and go back to what I was working on originally [14:12] gary_poster: after the morning chat can you bring me up to speed on the CI stuff? [14:12] sure thing hatch [14:12] thanks [14:14] benji: review done - just trivial stuff but I think you might agree :) [14:14] cool, I'll take a look [14:25] teknico: out of call [14:25] teknico: looking at your paste [14:25] teknico: how about just DestroyRelation("foo", "bar") ? [14:26] rogpeppe, you asked for it: :-) http://pastebin.ubuntu.com/5649498/ [14:26] lol [14:26] hatch: thanks for the review, I've responded, most interestingly to the asynchonicity issue [14:27] teknico: interrrresting... [14:28] benji: so wrt the done() - I meant to put the done() in the event callback [14:28] jujugui call in 2 [14:29] teknico: that doesn't look like it's related to the DestroyRelation. it may be a genuine, honest to goodness bug. :-) [14:29] right now "potentially" the conn.msg() call could fire, and before the callback is run it could run the assert [14:29] rogpeppe, nice [14:29] teknico: could you paste me a branch url please? [14:29] this is a huge MAYBE - but one that would be damn near impossible to track down :) [14:29] rogpeppe, https://code.launchpad.net/~teknico/juju-core/fix-cleanup-in-api-tests [14:29] rogpeppe, and now it's my turn to have a call [14:30] I'm torn between putting in a done() to be pragmatic and resisting voodoo. [14:30] teknico: ok, that'll keep me busy for a bit... [14:30] rogpeppe, what if I just leave that last one out for now? [14:31] teknico: let me try to get to the bottom of the issue first [14:31] rogpeppe, ok [14:31] teknico: it *should* work, i think [14:42] benji: yeah - I can see it never being an issue but I would like to err on the side of caution :) [14:45] rick_h_ possible to get that review? [14:45] rogpeppe, out of call, shoot when ready [14:45] Some morning humor: https://github.com/joho/7XX-rfc [14:46] hatch: ah, yea. link me again please? It doesn't show in my codereview since i didn't participate yet [14:46] https://codereview.appspot.com/7815047/ [14:47] Makyo, ha! that's nicely comprehensive, except for one glaring omission: no mention of mysql [14:47] teknico, Hah! [14:47] teknico: try this: lp:~rogpeppe/juju-core/tekniko-fix-cleanup-in-api-tests [14:48] Makyo, otoh, it having to be on *github* is slightly unnerving, do they plan that many revisions? [14:48] RFPR - Request For Pull Requests? [14:49] rogpepbe, I will, I mean rogpeppe ;-) [14:54] rogpeppe, while tests run, did that last failure actually expose a bug or not? [14:54] teknico: no, it didn't [14:54] teknico: i'd missed the assertion failure higher up the log [14:54] teknico: i *think* that branch should give you most of what you need [14:54] rogpeppe, good [14:55] teknico: you can look at the diffs to see what i did to solve the problem [14:56] rogpeppe, I did, and I may even have understood the approach :-) [14:56] teknico: :-) [14:57] rogpeppe, the TestOperationPerm tests pass, great job, thanks! [14:57] rogpeppe, now running all apiserver tests, and then the whole thing [14:57] teknico: cool [15:00] hi bcsaller, free to chat? [15:00] bac: winding down call, maybe 5 minutes [15:00] bcsaller: great [15:15] hatch: heads up, I got a conflict merging your branch into a fresh trunk copy in app/views/topology/service.js so an quick pull from trunk should make landing easier [15:19] bac: still on call, I'll ping you soon [15:19] ok [15:21] hatch: ping [15:21] hey sorry in call [15:21] hatch: ah, np. got ? for you when you get off in QA here [15:21] sure [15:30] rick_h_ guichat? [15:30] hatch: sure can, sec [15:30] bac: ok, off call [15:31] bcsaller: ok. so you want to hangout now or in a few minutes? [15:31] benji: LGTM with a few questions [15:31] cool, thanks [15:31] I'll be done with your review in a minute. [15:31] bac: we can do it now but I think normal chat room is taken [15:32] bcsaller: i'll make one [15:35] uhm, I wonder why compiz is a bit crashy lately [15:37] teknico, has been for me, too. [15:37] Dash, too. [15:37] Blacklisting my work directory helped, so that it wouldn't search through branches. [15:38] Makyo, oh, nice, if it speeds it up it's definitely worth it, how do I do that? [15:39] teknico, System Settings - Privacy - Files - Don't record activity in the following folders. [15:39] Makes a big difference, even with "Record activity" set to off. [15:40] Makyo, why do I have no Privacy icon in system settings? [15:41] teknico, 12.10? [15:41] Makyo, yep, are you on raring? [15:41] teknico, Not yet. [15:41] uhm [15:42] Another that helped, if you have ccsm, is to go to the Unity Plugin, Experimental tab, and set Dash Blur to No Blur. [15:44] Makyo, found that one, thanks, but now the dash is a bit too transparent [15:44] Static Blur seems a nice compromise, whatever that means :-) [15:48] oh man my internet is so slow right now [16:03] rogpeppe, it's finally there: https://codereview.appspot.com/7873046 [16:03] teknico: thanks! looking... [16:06] rick_h_ FYI I have been using tmux for my ubuntu ssh and it's workign really well although it triggers a lot of 'changed' events causing my terminal tab to flash when nothing has changed [16:06] I don't know if you have run into the same thing before? [16:06] hatch cool. yea any activity in the Window will activate things. [16:07] but there is no activity - does it maybe poll which triggers activity? [16:08] hmm I use it for irc and it has a clock that updates and join/part messages [16:08] so it's always updating [16:08] ahh ok no problem I was just curious really [16:11] rick_h_droid I pushed the new merge - it all worked properly here [16:11] try a fresh checkout [16:12] I'm just about to run the tests in IE [16:13] ok will do [16:13] but first I better let these updates finish - updating a vm and tryign to use it at the same time is....well damn near impossible lol [16:20] gary_poster: it's looking like travis can do bzr [16:20] hatch, really! interesting [16:20] I thought it was github specific [16:20] yeah - i'm trying to load more details but my internet is VERY slow [16:20] will link in a sec [16:20] :) [16:22] hatch, I looked before and stopped reading after this sentence, actually: "As a free community service, Travis CI limits build duration to about 20 minutes" [16:22] unfortunately [16:22] that's not us [16:22] teknico: reviewed [16:23] gary_poster: they have a 'pro' version in beta and it's also OSS so we could run it ourselves (if we wanted) [16:24] no reason to run YA CI system AFAIK. :-/ [16:24] the hosting part is the good part [16:24] hatch, going to go get some lunch. biab [16:24] rogpeppe, thanks but... oh no! latestUnit! I don't want to lose it! [16:24] sure - I agree [16:24] just letting you know :) [16:25] cool :-) [16:25] rogpeppe, :-) can it be useful somewhere else? [16:25] teknico: you'll just have to treasure it in your memory (and bzr history) :-) [16:25] rick_h_droid the lock-zoom branch passes the tests in IE as well so as long as you can confirm you don't get those errors with this merge then I'll submit [16:25] teknico: nothing is lost :-) [16:25] hatch: so I'm still seeing the error/issue when I go to all notifications, then click 'view details' on the first one [16:26] hatch: and the same issue on the N10 with the view details, but working on the N7 [16:26] well what the... [16:26] I can't even reproduce in IE [16:26] haha [16:27] this is on a fresh checkout? [16:27] I get it in both stable chrome and the beta chrome on the N10 [16:27] hatch: yes, all merged with trunk, pulled your latest updates, make clean-all, make, make devel [16:27] ahah! [16:27] hmm, /me goes to try the test-server on the machine [16:27] I was able to reproduce it [16:28] :D [16:28] which one? [16:28] Uncaught TypeError: Cannot read property 'parentNode' of null [16:28] ah cool [16:28] damn I'll have to write a test for this now [16:28] lol [16:30] wow, crazy to see how tests run in 17.8s on desktop chrome, passing 50s on the N10 [16:31] rick_h_ that error is on trunk [16:31] so I'm going to merge this then create a ticket for it [16:31] are you ok with that? [16:31] that's why I couldn't reproduce it :D [16:31] hatch: sure thing. So my QA is that N7 looks ok, N10 has issues we don't know about yet [16:32] ok, although not ideal, I don't have a N10 to test with [16:32] though after 159s :( all tests do pass on the N10 [16:32] hatch: yea, I can try to help at some point but really under the gun. [16:32] yeah - when I was starting with the N7 - I could simulate the needed events but manually they woudln't work [16:32] so the tests would pass but it woudln't work hah [16:59] anyone know what ports I need for juju communication? [16:59] just 22? [17:01] so far I have 22, 80, 443 [17:05] hatch juju communication from the GUI? to what? [17:05] I was just thinking what ports things like 'juju bootstrap' communicates through [17:07] hatch, ah. not sure. would have guessed 22. bcsaller, you happen to know? [17:07] that's entirely possible - I'm just spinning up the instance now [17:07] so I haven't gotten that far [17:07] oh ok [17:08] sorry I googled tarmac and realized I had no idea what was going on so took the EC2 setup side [17:08] s/going/doing [17:08] :) [17:08] hatch, cool. I may need to do ec2 also. was about to in fact [17:09] jenkins has been waiting for an m1.small for almost an hour now [17:09] on canonistack [17:09] oh that's what it was doing [17:09] I was wondering [17:09] yup [17:09] for the bootstrap node [17:09] fun [17:10] oh geeze - then it will definitely fail because it won't be able to provision any more :) [17:10] unless it waits forever for that. [17:11] guichat to run over what I am to do with this micro instance? [17:11] y [17:29] rogpeppe, all tests pass, landed, fingers crossed :-) [17:30] teknico: cool, thanks! [17:32] doing this CI I wish we were in an office so I could do this http://imgs.xkcd.com/comics/compiling.png [17:32] :D [17:46] gary_poster: Unexpected initial authentication state: [True, None] [17:46] have you seen that one? IE test_staging_services error [17:47] hatch that's a diagnostic I added for that test. The good news is that I never actually got the diagnostic before because of a problem I apparently fixed in the previous revision :-) [17:47] lemme remind myself... [17:48] hatch, that should just be info--how did the test itself fail? [17:48] I'm not sure I'll have to review the video [17:48] oh wait [17:48] it didn't fail [17:48] hatch pastebin the output for me pls? [17:48] yay! [17:48] good that makes sense [17:49] man do these tests fly now :) [17:49] heh, good [17:50] chrome and firefox both say " unable to complete test run." ERROR [17:50] they are alsmost all done then I"ll link you the output [17:55] hatch so let's go to guichat === hatch_ is now known as hatch [18:09] 3x-5x speed increase for Y.Base coming in the next YUI [18:09] OOoOOOooooo [18:11] yay [18:12] that's HUGE considering that base is in everything [18:12] haha [18:12] gary_poster: my telepathy tells me that now is a good time for you to talk about my next task [18:13] benji :-) ok to the guichat [18:24] ok it takes ~16:30 to start the tests [18:37] gary_poster: firefox exhibits the same 'caching issue' that IE does [18:38] that's why the GUI tests are failing [18:39] hatch, ugh [18:40] hatch, btw on IE I have a new opinion about the Javascript Error thing and whether we should retry. It's not cut and dry IMO. We can have that conversation later [18:40] chrome finishes the unit tests then hangs [18:40] hatch, should timeout eventually [18:41] then we can see why the numbers are wrong [19:09] hatch: got a sec to sanity check this build issue? http://paste.mitechie.com/show/914/ [19:10] jcsackett: maybe you know, did you deal with something like this ^^ [19:10] it looks like it's trying to load the module from YUI vs the gui src [19:14] rick_h_: no, never saw that. has tabview been modified since i checked it in? [19:15] jcsackett: no, I did move it because I wondered if it was a path issue. It was originally just widgets/tabview [19:15] rick_h_: but you got this error with it as widgets/tabview too? [19:16] jcsackett: yea, hmmm, you konw it was working. I have a running make devel that was working ok. I wonder if something went batty. make clean_all time [19:17] I end up with a app.js.map laying around. /me goes through bin/merge-files [19:18] if I don't require the tabview in my view code it works [19:19] so I had a working setup, added the tabview, but didn't restart the make devel and it kept working. Once I stopped to lint/push it blows up [19:22] bizarre. [19:22] yea, grrr at this build stuff sometimes [19:22] * jcsackett nods [19:41] ok back [19:42] rick_h_ hae you solved the issue? [19:43] hatch: no, I'm tracing through how this merge-files gets it's list of files to merge/build but it's tedious [19:43] hatch: some how the script thinks yui should have a node_modules/yui/browser-tabview/browser-tabview module [19:44] hatch: but we've got browser-tabview listed in our modules-debug and it's in the list and picked up as far as I can tell so far [19:45] that will happen if the module name is not specified [19:45] 'module name is not specified' where? [19:46] well if the module name isn't registered it'll try to load it from where yui.js was loaded [19:47] hatch: ok, getting closer. The if (details && details.requires) { [19:47] check is failing for the tabview module [19:47] looking into wtf dteails/details.requires is [19:50] oh hell...tabview module was a YUI().add instead of YUI.add [19:50] so it broke out of all the hacks in the build system to replace YUI.add and such I guess [19:51] thanks hatch jcsackett, all good now [19:51] rick_h_: well damn, sorry for that crap. [19:52] jcsackett: heh, all good. Simple error. Just hard to debug. Looking at the end of the files in the requires part vs the top of the file. [19:52] rick_h_: haha oh I hate that - I've done that so many times [19:52] jcsackett: helped me also realize that the namespaces on the browser-tabview were reversed juju.browser.widgets vs juju.widgets.browser like elsewhere [19:52] hatch: hah! well lesson learned. Next time I see it it'll jump out at me more [19:53] and I figured out how to pdb up a node script as well [19:57] pdb? [19:57] oooo that namespace thing should probably be fixed....no? [19:58] hatch: pdb is the python debugger; i'm guessing rick_h_ means he has figured out use of the node equivalent? [19:58] hatch: yea, I've got it correcting here [19:58] jcsackett: right, basically node debug xxxx allows you to do debugger; in a script [19:58] but it's fugly ... /me misses pdb [19:59] rick_h_: our tests are run via node when run in the command line, right? so we could potentially command line debug failures? [19:59] ohh ok :) I was like "pdb? new node debugger??" h [19:59] aha [20:01] curses!!!!! now extend failed, verify dependencies in tests. /me pulls plug [20:05] rick_h_: did you add any extends? [20:07] jcsackett: no, didn't think so. looking over diff [20:12] hmm, Y.TabView is undefined [20:13] but it's manually defined in merge-files [20:14] that's...bizarre. [20:14] rick_h_: you're hitting all the fun issues with this one, aren't you? [20:15] jcsackett: heh, well the dippy things works from the app. It's just getting build/test happy so I can submit some work [20:17] * jcsackett nods. [20:17] that *is* where the fun goes. [20:18] hmm, that's odd: the units in an error state are grey (like running instances); I would have expected them to be red [20:19] rick_h_: do we think the charm-small widget will change size depending on where its used, or can we assume constant width? i'm thinking it should have a "width" attribute for purposes of placement in the category container. (and the slider, probs). [20:20] jcsackett: so for now I'm thinking it'll be constant and determined via css. Why a ATTR? [20:21] rick_h_: the charm container wants to be some multiple of the charm small width. and that will vary based on the "max" it shows before being expanded. [20:21] so it would be good if it could get the width from small and set its own width correspondingly, right? [20:22] jcsackett: so I'm thinking that what we'll do is to have the number to show be an ATTR on the container and let the charm-smalls just be block levels and will float/resize dynamically based on space via css [20:22] jcsackett: might attach it with the grids framework later on [20:23] rick_h_: ah, yeah, that works. [20:23] and means less work for me, so i'm down with that. [20:23] so I'd just default to say '5' in the container and we'll work the rest out from that [20:23] oh man this fixes it but damn is it evil [20:25] ? [20:28] https://code.launchpad.net/~rharding/juju-gui/fullscreen_charmview/+merge/155595 L466 [20:28] jcsackett: ^ [20:29] rick_h_: that's bizarre. [20:29] but if it works, it works. [20:29] (apparently bizarre is my new favorite word today) [20:39] hatch: I'm going to try to get this ready for review here in a sec. It's not complete. I'm coming up on a big diff at this point and will spend tomorrow refactoring, but it 'works' so want to close up a loop. [20:40] sure [20:40] fyi - did you look into node-inspector? [20:40] hatch: no, didn't look at node-inspector [20:40] ok it's just another option for debugging node [20:40] ah bah...needed a -edit on there. One more ride... [20:40] cool, will keep that in mind [20:50] rick_h_: isn't this way late a day for you? [20:51] jcsackett: yea, well gotta get stuff done. Trying to go late from now until launch. Have a call in an hour anyway so meh [20:51] go lbox go... [20:55] rick_h_ ok I'm ready [20:55] just needed to fire off a potential working CI [20:55] very potential [20:55] lol [20:56] hatch, another crazy idea: see what versions of chrome saucelabs offers on different platforms and try switching our chrome to other platforms/versions to see what happens [20:56] sure thing [20:56] I'm hoping it's a bug in the after [20:56] I had to push to my own branch - it woudln't let me push to yours [20:57] hatch, yeah, makes sense [20:57] we can only share in ~juju-gui branches [20:57] (or other teams we both are members of) [20:57] ohh ok [20:58] gary_poster: very simple change this time http://bazaar.launchpad.net/~hatch/juju-gui/ci/revision/467 [20:58] and it still works locally [20:58] cool hatch [20:58] so as long as that wait_for_script() works as advertised it should work [20:58] :-) [20:59] hah [20:59] famous last words - I might as well quit now [20:59] lol [21:01] rick_h_ are we going to get a codereview url? [21:01] or is it just hung up in internet land [21:11] hatch: sorry, battery died at the coffee shop...lbox take 3 [21:11] lol [21:12] yea, fail submit for this one...fighting me every step of the way [21:13] for some reason I am getting a ton of visits to my blog to invalid php urls [21:15] hatch: jcsackett https://codereview.appspot.com/7581045 there we go [21:15] awesome [21:16] so it's incomplete but it 'works' so I'd like to get it in and on staging for UX to play with while I spend tomorrow refacoring/solid'ing it up [21:33] review done [21:34] benji: your propose won't let me actually view any diffs [21:34] could you try proposing again? [21:36] everything looks ok as far as the merge goes [21:45] gary_poster: are you still around? === OutOfControl is now known as benonsoftware [23:16] hatch, no :-)