[11:31] * mariusko has brokes juju-gui again... [11:31] broken [11:33] mariusko: you deployed using lp:juju-gui as juju-gui-source? [12:02] is anyone else having problems logging onto the kanban board? [12:03] benji: I had to re-login over the weekend but in it ok today [12:03] it is acting flaky === gary_poster|away is now known as gary_poster [12:06] hi everybody! [12:07] yeah, can't log in to kanban [12:08] bac: re bug 1164593: missed to specify that the described behavior happens when the GUI is connected to juju-core. I just updated the bug accordingly, sorry about that. [12:08] <_mup_> Bug #1164593: GUI hangs on the service detail view < https://launchpad.net/bugs/1164593 > [12:09] frankban: ok, thanks [12:10] benji it worked for me if I went to http leankit. That redirected to https, and then it worked. Pretty annoying though [12:10] oh [12:10] didn't really work :-( [12:11] mm, retrying worked [12:11] I finally managed to get in but I'm afraid to click on anything because it might break. It feels like they have one or more app servers in a LB pool that is acting up [12:12] ah ok [12:14] * frankban lunches [12:18] hey benji. what's the story with the "expose service config information via Go API" card, do you know? kanban still flaky so can't see description, if there is one [12:19] gary_poster: I'm wondering if it was found to be a duplicate. [12:19] oh cool benji. so we have service config and constraints in go api deltas, to your knowledge? [12:20] gary_poster: oh, I was (quite) sick Friday, which you may not know because I forgot to put it in the system which I am doing right now. [12:20] kanban board behavior not cool [12:20] oh! ok, benji, glad you are better [12:20] I'm not certain, but I am 90% sure someone (can't remember who) said that it was on Friday. [12:21] [oh dude, was so sick; barely back to vertical now] [12:21] ugh :-/ [12:21] I suggest we kill the card and let it raise itself as a zombie if need-be [12:21] sorry [12:22] benji, "it was on Friday" -> what was on Friday? [12:23] kill card...mm...this will remind me to resolve the question, which I need to do :-) [12:23] said "it was [a duplicate] on Friday" [12:23] oh ok [12:23] English, you so crazy. [12:23] :-) [12:23] ok thanks. will leave card for now until I get confirmation that service config is done === teknico_ is now known as teknico [13:12] frankban: nope, stable [13:12] I also struggle with with a CSS-less site with "Loading the Juju GUI" [13:13] If I don't make the URL different by adding ?something [13:13] I wonder if the caching settings are wrong [13:13] gary_poster, hi, yes, config get and set are in, I don't know what else that card could refer to [13:13] teknico, awesome! the deltas, though? [13:14] do we need deltas for config? Are we sure we use them in the app? [13:15] gary_poster, don't know about them [13:16] rogpeppe, hi! it looks like we are making good progress. I'm not clear yet on whether we have the config information in the go deltas yet, but AFAICT after quick zooming this morning, that is either done, or the last go-side change we need. Yay! On a related note for the future, I have a suspicion that the juju core API for annotations may introduce the possibility of unpleasant race conditions across annotation [13:16] sources, and this may be a practical concern when we bring Landscape annotations into the fold, for instance. Specifically, if Landscape annotates an object with Landscape annotations, and we annotate an object with x,y locations, in the Python API (merged updates) there is no chance of a race condition between the two. In the Go API, IIUC, we must get annotations, change them, and set them, which introduces a rac [13:16] e condition across concerns [13:16] sorry, had to finish that up :-P [13:17] benji, good question. [13:17] We certainly expect them to be on the model [13:18] and config can change dynamically [13:18] as opposed to constraints [13:18] so it would idealy be in the deltas [13:18] mariusko, what charm [13:19] mariusko, the ~juju-gui charm will become the official charm once jujucharms.com is flushed [13:19] We test with that before release, and we run CI tests with it and trunk several times a day [13:21] mariusko, if the problem is when deploying with that charm, we'll jump on it asap. we have seen neither of the problems you report ourselves though, fwiw. [13:21] (which is definitely not to imply they do not exist() [13:22] mariusko: you can try removing the appcache from chrome://appcache-internals/ [13:22] good call on the CSS frankban [13:23] gary_poster: FWIW, I bootstrapped a juju-core env ~5 hours ago, and I don't see the settings in the delta stream, nor the status [13:23] frankban, I wrote a novel to rogpeppe above which included a concern about the Go annotation API. Does that concern make sense to you? [13:23] frankban, ah :-( [13:24] the status we definitely need now [13:24] the config we will need but we *might* be able to do it after 13.04 [13:24] gary_poster: do we also need the constraints? I remember you said we get them from the charm maybe? [13:26] gary_poster: hiya [13:27] gary_poster: i'm not sure i see why you need to get-change-set annotations [13:28] frankban, no, we get is_subordinate form the charm. constraints and config have value in the delta stream only when we are viewing them explicitly, and possibly when we are editing them. We would want to be able to see when the config changed as an alert, I suspect. also, a nice to have would be to see changes while you are editing them. We could push both of those off to post 13.04 if what I describe are the on [13:28] ly use cases, and if we already explicitly get/update the constraints and config when we look at them now [13:28] gary_poster: i think we can set x and y without affecting landscape annotations [13:28] rogpeppe, ah ok, I wanted to verify my memory of the API before I bothered you, but I was losing state in my brain so I had to dump :-) . DO I remember correctly that the Go API is to set all annotations? [13:28] ah no! [13:29] you can set an annotation to null [13:29] and that removes it [13:29] right? [13:29] gary_poster: empty string, but yes [13:29] rogpeppe, ok cool, sorry for the noise on that then. excellent. So in terms of status of the deltas: [13:29] - we need status in there [13:30] - config is nice to have [13:30] - constraints is also nice to have, and lower priority [13:30] gary_poster: i'm getting there; i've done quite a bit of refactoring (the allWatcher is now in its own package) and next up should be the statuses. [13:31] rogpeppe, great! I certanly saw a lot of work from you fly by [13:31] rogpeppe, AIUI this Thursday is the "we really should have everything in Raring now" and next Thursday is "um, sorry, it is too late, you can't even have bug fixes" [13:33] rogpeppe, when would be the soonest to hope for statuses in the deltas? Also, I take it that these changes are entirely on your plate? [13:36] gary_poster: hopefully by end tomorrow, if implementation goes to plan [13:37] ok cool rogpeppe thanks. let me/us know if there's something we can usefully put in our plate [13:37] on [13:37] gary_poster, rogpeppe: I think this is related: bug 1161848 [13:37] <_mup_> Bug #1161848: Malformed charm metadata error when a charm is deployed using the API < https://launchpad.net/bugs/1161848 > [13:38] more recently, when ServiceDeploy is called, I started seeing juju-core panics [13:38] frankban: interesting; thanks for the report. related to what? [13:38] thank you, yes frankban. My understanding is that this is not specific to the API though, right? [13:38] rogpeppe, related to us being done successfully, I think :-) [13:39] frankban: was that against a newly bootstrapped environment? [13:39] gary_poster: the API call is what juju-core expects. I am grabbing logs about the panic [13:39] rogpeppe: against an env bootstrapped ~5 hours ago [13:39] (this morning) [13:40] frankban: with --upload-tools, presumably? [13:40] frankban: have you tried doing "juju deploy minecraft" against the same environment? [13:40] frankban, I expected that this error would also happen if you tried to deploy minecraft without the GUI, was my question. [13:41] (without the API) [13:41] frankban: i'm surprised there's a difference between the api deploy and the cmd line deploy, actually [13:43] (right, that was what I was trying to say) [13:44] rogpeppe, gary_poster: the cmd line deploy works well, here is the error and the subsequent panic when ServiceDeploy is called via the API: http://pastebin.ubuntu.com/5689443/ [13:44] ahha [13:44] rogpeppe: nad yes, --upload-tools was used [13:44] frankban: ah! [13:44] s/nad/and [13:45] frankban, so we probably now have two bugs, yeah? the panic because of the home, and the relation name problem [13:46] rogpeppe, if you want us to get some people to work on these, and consult on you initially for fixes, that would be great by me. [13:46] consult with you initially for fixes [13:46] gary_poster: that would be great, thanks! [13:47] I noticed my preposition use today was a bit off generally :-P [13:47] gary_poster: i feel a little overloaded right now [13:47] rogpeppe, completely understood. I'll find some people and send them your way for a pre-imp discussion, and then hopefully we can get out of your hair [13:48] mm... frankban and/or teknico, are either of you up for those? [13:49] gary_poster: yes, this seems a different bug. but I am confused about "relation name". you mean the charm not found error? [13:50] frankban, your bug (https://bugs.launchpad.net/juju-gui/+bug/1161848) doesn't report a missing charm as I read it ('malformed charm metadata found in state: charm "mysql" has mismatched relation name ""; expected "shared-db"') [13:50] <_mup_> Bug #1161848: Malformed charm metadata error when a charm is deployed using the API < https://launchpad.net/bugs/1161848 > [13:50] do I misunderstand [13:51] frankban: check out recent remarks on #juju-dev [13:51] gary_poster: yes. so I think we have 3 different issues. 1) CharmInfo returns "charm not found", 2) ServiceDeploy generates a panic and 3) the old bug, that could be still valid [13:51] gooood morning [13:52] morning hatch [13:53] frankban, ack. 1 and 2 seem related to me, but that's a guess. [13:53] gary_poster: this branch factors out the allwatcher: https://codereview.appspot.com/8458044/ [13:53] cool rogpeppe! So if we want to refactor the allwatcher we will still have that base for what we want. [13:53] gary_poster: seeing the discussion in #juju-dev, I have the same impression [13:54] gary_poster, yep [13:54] gary_poster: exactly. the new package gives the basis for any combined watcher you might want to concoct [13:54] jcsackett: hatch or others can I beg for some reviews today please? https://codereview.appspot.com/8513043 for huw and https://codereview.appspot.com/8488043/ for myself [13:54] great [13:54] gary_poster: it's the change i was putting off, but it became necessary. [13:54] rick_h_: sure [13:55] hatch: ty kindly sir [13:55] ah ok rogpeppe [13:55] frankban, also we can't tackle 3 until 2 is handled, rt? [13:55] gary_poster: yes [13:55] or at least it will be more difficult [13:57] cool. you working on 1 and/or 2 then frankban? If so, suggest with Roger soon, and planned handoff with someone tbd (maybe me and I would rope in someone with more go experience?)if it takes you past your EoD [13:57] suggesting talking with Roger soon, I meant [13:57] gary_poster: sounds good [13:57] cool thank you [14:08] luca____: howdy, heads up. I promised you and jovan2 an link to view for the config tab on the browser: http://uistage.jujucharms.com:8080/bws/fullscreen/precise/apache2-2 and click on the configuration tab below [14:11] hatch: did they update getData to look for the data- attribute? I could have sworn that was the big confusion with that when they added it. It didn't work at all with the attributes in the dom [14:12] rick_h_: yeah a long long time ago [14:12] it now works for both [14:12] I forgot about that confusion :) [14:12] hatch: hmm, ok. I guess I got in my head that it's never what I expect since so ditched its use. [14:12] hatch: ok cool then. missed that change/update along the way I guess [14:12] hatch: thanks for the look over [14:13] yeah that's fine - It doesn't really matter which one you use I was just pointing it out [14:13] no problem [14:13] hatch: yea, good to know :) I'd still not know they changed it. [14:14] :) [14:14] does Huw's branch need QA? [14:14] hatch: you can, but it's pretty simple just add a column/not. Not much to it [14:15] no real crazy style/etc stuff to check works correctly. [14:15] rogpeppe: please ping me when you are available for a pre-imp call re bug 1166224 [14:15] <_mup_> Bug #1166224: Panic when calling ServiceDeploy via the juju-core API < https://launchpad.net/bugs/1166224 > [14:15] teknico, thanks for readthedocs improvement :-) [14:15] rick_h_: cheers Rick, I'll check it out [14:15] frankban: will do. in a call right now [14:16] rogpeppe: thanks [14:16] luca____: yea, so feel free then to mark that up and we can update the designs if needed/etc. [14:16] Makyo, benji, bac, teknico you all have readthedocs privs: thank you for getting me your user names [14:16] gary_poster, mp, I also put a requirement for Sphinx in there [14:16] cool [14:16] gary_poster: yay [14:16] gary_poster, yeah, I noticed ;-) [14:17] ;-) [14:18] gary_poster: my rtd account is, surprisingly, frankban [14:18] frankban, :-P you are added [14:18] :-) [14:18] :-) thanks [14:24] rick_h_: I like the layout of the configuration options. I would put the default value before the explanatory text though. [14:24] jovan2: ok. can move that without an issue. [14:25] I'll drive-by that in the branch I've got going right now [14:25] rick_h_ cheers [14:26] Hey bac, thank you very much for reviewing/helping BjornT. That looks like it was more work for you than I had expected, and I'm sorry about that, but I'm glad he is unblocked [14:26] rick_h_: ugh I hate how less's mixins look like class names [14:27] hatch: +1 [14:27] gary_poster: it was no problem. easier to review his changes than to do the work! [14:27] :-) cool [14:27] gary_poster: he made one change that will help us in that it will avoid looking at the archives [14:27] hatch: so when you convert it all over to sass let me know :) [14:27] lol [14:27] bac, oh excellent [14:27] I wish sass wasn't written in ruby [14:27] frankban: ready when you are [14:27] hatch: I'll do the review [14:28] rick_h_: haha it probably woudln't be THAT much work [14:28] hatch: https://github.com/Kronuz/pyScss is what I use in my projects. python ftw [14:28] most of the stuff is identical [14:28] lol of course you do :P [14:28] hatch: well I wasn't going to isntall ruby just for css compiling :P [14:28] lol good point [14:29] this machine has so much garbage installed and modified it's a miracle it's even still running [14:29] rick_h_: got a second to chat? [14:30] rogpeppe: cool, https://plus.google.com/hangouts/_/02bb45411739e441fe107c9f66e2a8cc36ba4ba7?authuser=0&hl=en# [14:32] brb [14:33] jcsackett: yep, sure thing [14:33] hatch: I'm goign to kick you [14:33] gary_poster: testing it now, but it is broken: "nodejs : Conflicts: npm" [14:33] It must stop installing npm, as it is included in nodejs package [14:36] mariusko, I saw that when it landed but it worked for me. hatch, ^^^. mariusko I am unhappy that you are encountering issues that we don't see, and apologize. :-( Send me an email @ gary.poster@canonical.com with the commands you are running, even if they are obvious, and I will run them myself, fix what I can and we can go from there. [14:37] where "going from there" hopefully includes figuring out what we are missing in our QA [14:39] It's not anything special, and it is not so easy to reproduce, as it works first, and then fails. It could be too little memory on the machines that causes it to fail [14:45] rick_h_: what did I do now? [14:45] hatch: I specifically moved that from an ATTR into a function because of your hate for 'empty attrs' [14:46] but it's not empty [14:46] hatch: I started out with it as an attr and a getter and moved it to a function before -cr for you :) [14:46] it would be a flag [14:46] no? [14:46] hatch: no, it's completely based on the class.name [14:46] new charmBrowser({fullscreen: true}); [14:46] hatch: no, look at what isFullscreen() does. It checks for a match in the class name [14:47] mariusko: gary_poster: one of our dependencies doesn't like Node 10 so I had to roll it back to 0.8 [14:47] the MainView is extended by SidebarView and FullscreenView to provide the different bits, but they're so common in most places. [14:47] is the charm still trying to install 10? [14:48] hmm [14:48] I think it's going to be fragile - if someone changes the name and then all of a sudden the fullscreen stops working it's going to be very hard to diagnose [14:48] don't you think? [14:48] hatch: right, but there's a test that it is correct so the test will fail right away [14:49] hatch: but the render code and the template is shared between fullscreen/sidebar. Only fullscreen template needs to add a column to fill some space. [14:49] yeah I saw that....hmm [14:49] hatch: so the best way is to create a simple check var the template can key off of to determine if it can use 'wide view' or 'narrow view' in the process [14:49] yeah - I suppose it's ok with that test [14:49] hatch: and if I do it manually with an ATTR then every call site has to be kept in sync vs a class name which is safer imo [14:52] gary_poster, ping. [14:53] mariusko: can you check which version of node is being installed? it should be 8.22 [14:55] Makyo: I see you assigned yourself to that odd bug [14:55] any ideas about what's going on? [14:56] hatch, Not yet, adding a ton of logging, though. [14:56] I spent a few minutes on it and I am almost 100% certain it's a D3 'bug' [14:56] bug is in quotes because it's probably caused by our code [14:56] haha [14:58] hatch, yeah, there are a few places where position is set and I'm wondering if something's getting knocked around there. Digging the debugging console at least. [15:04] Makyo, sorry, missed you. on call [15:04] gary_poster, np, two quick questions when you get a moment. [15:06] frankban: there were no changes with slider in 3.10 so will have to investigate further but maybe once PR2 comes out [15:07] hatch: sounds good, I don't think is an high priority problem [15:10] frankban: and for the record I approve of your YUI version restriction :) [15:16] rick_h_: when you next talk to Huw could you ask him why he is mixing units? re the fix for the button height issue [15:16] pt & px [15:16] hatch: k, will do. [15:18] hatch: nope, it is 0.10.3-1chl1~precise1 [15:19] frankban: i understand the problem with bug 1164593. when i implemented the go API for ServiceGet i only returned the data required by 'juju get '. but the python API included more information. so now i will add the constraints and other required bits to the Go api. [15:19] <_mup_> Bug #1164593: GUI hangs on the service detail view when connected to juju-core < https://launchpad.net/bugs/1164593 > [15:19] mariusko: thanks for checking - hmm that's very odd because the most recent code in lp uses the legacy repo which I was sure topped out at 8.22, [15:19] bac: great [15:20] hatch: which ppa? The charm itself is an old one for precise [15:20] mariusko: here is the line in question http://bazaar.launchpad.net/~juju-gui/charms/precise/juju-gui/trunk/view/head:/hooks/utils.py#L81 [15:20] ohh you're not running from trunk [15:21] sorry I'm still new to this game so I don't know all of the questions to ask yet :D [15:22] https://launchpad.net/~chris-lea/+archive/node.js-legacy [15:22] there is the PPA - so it looks like in trunk it should still be deploying 8.22 [15:23] bah, now it won't install and then not upgrade or retry [15:32] :/ [15:33] would you like me to give it a go using latest ? [15:33] I can spin up some instances but it might take a while :) [15:37] it's entirely possible that the dependency has been updated to work with 10 now and this is another issue entirely [15:37] ok [15:39] bcsaller: did you need another review on your annotations branch? [15:39] hatch: making the changes gary wants now so I can push another soon [15:39] alright no problem [15:48] hatch: hmm, the line is correct: BUILD_REPOSITORIES = ('ppa:chris-lea/node.js-legacy',) [15:51] mariusko: alright I'll spin up some instances to debug this [15:51] great [15:54] Makyo, questions now or in/after daily call? [15:55] gary_poster, in would be fine. [15:55] cool [15:55] mariusko: ok instances are being spun up so I'll get back to you once I have something [15:59] gary_poster: I can't log into the kanban so can you pm me that link? [15:59] jujugui call now [16:00] CalledProcessError: Command '['ssh', 'ubuntu@10.55.61.25', 'sudo', 'service', 'juju-api-improv', 'restart']' returned non-zero exit status 255 [16:00] https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Aia4W3c4fbL-dFlYQm1Zd1dGTVE5S2o4ZUVLam5IMnc#gid=0 [16:07] hatch: i think there might be some machine reuse going on here. currentry trying a new node [16:07] / instance [16:08] mariusko: I'm actually getting some 503's on a bunch of other PPA's [16:16] * mariusko got it working now. Let's see how long it lasts. [16:29] Makyo, bcsaller: i just noticed the rendering of the service blocks in FF on OS X is whack. the inner circle is at the bottom right corner and the indicator ring is outside the box altogether. [16:29] bac, anything in the console? [16:30] bac: Is that true after the 1st delta? Its mostly thowing an error before the draw is done [16:30] death before translation! [16:30] [12:30:36.523] Firefox can't establish a connection to the server at ws://uistage.jujucharms.com:8081/ws. @ http://uistage.jujucharms.com:8080/juju-ui/assets/all-yui.js:28 [16:31] I think there would be an actual exception in our code for that to happen [16:41] Is the unit view expected to work with the go backend? I just get a loading message. There are no (related) errors in the JS console. [16:41] I can't help but think I'm doing something wrong. Every time I try to do anything with the gui and go it is a slow, painful process. [17:00] does deploying work with the go backend? === deryck is now known as deryck[afk] [17:29] gary_poster: next CL in the pipe: https://codereview.appspot.com/8487044 [17:29] gary_poster: next up: statuses! [17:29] benji, the answer is in the mailing list ;-) [17:29] yay! :-) [17:31] benji, specifically in the "Handing off bug #1166224" message [17:31] <_mup_> Bug #1166224: Panic when calling ServiceDeploy via the juju-core API < https://launchpad.net/bugs/1166224 > [17:32] gary_poster: ah, darn, i forgot to write a load of tests [17:32] :-/ [17:41] I found a work-around for #1159870 but it involves enforcing two-finger dragging. It works, but isn't very discoverable. Perhaps something we can tool-tip? [17:41] <_mup_> Bug #1159870: Viewing service from popup on mobile causes service svg element to move < https://launchpad.net/bugs/1159870 > [17:52] Makyo: wasn't two finger dragging the default anyways? [17:53] hatch, well, it was the one that worked properly :) [17:54] haha ok ok [17:54] so when it's two finger drag it doesn't jump when you view services? [17:55] hatch, correct. It still attempts to fire drag events, but if we go with two-finger drag, we can set a flag to break out of drag if there is only one touch. [17:55] oh awesome [17:55] nice find! [17:55] that was driving me nuts [17:55] Meeee too. [17:56] Especially because, previously, panning wasn't working. [17:56] Is now, though. [18:11] (back from lunch now) teknico: thanks for the info [18:14] benji, yw [18:18] rick_h_: any idea why the valuechange woudln't trigger in the browser search tests? [18:18] 'browser search widget' to be specific [18:18] the one with the 200ms timeout [18:20] hatch: looking. It's not triggered? [18:20] intermittently [18:20] sometimes it even hits the 20s mocha timeout (if we remove the timeout in the test) [18:20] gary_poster: oh hmm, it's based on a _poll time in the YUI code [18:20] so maybe there's an issue with the test/poll interval crossing there? [18:21] value-change is used to detect things like pasting in which doen't fire events like keyup/etc to watch for changes. [18:21] to do that it runs a 50ms poll by default looking for changes to the value [18:23] yeah I've never seen it fail in the real world [18:24] hatch: yea, I've not seen it locally at all. Second, I'm debugging a failing test for some new code atm and I'll go back and look at that test and see if there's a shortcut/way to tinker with it [18:25] thanks - I tried wrapping it in a timeout to set the value but no luck [18:25] maybe if we set it repeatedly [18:25] haha [18:25] hatch: so I'm wondering if we can change the _poll interval on the module to be less/quicker [18:26] actually that sounds familiar [18:32] hatch: yea, so looking at that test I added a timeout to help make sure the poll event had a chance to fire [18:32] hatch: and I'd bet that on slower hardware/etc it's not getting to I guess... [18:33] well sure but one would think that it should fire in 200ms [18:34] hatch: so maybe we can change this in the test http://yuilibrary.com/yui/docs/api/files/event-valuechange_js_event-valuechange.js.html#l44 [18:34] that's a long time really [18:34] ahh change it to poll faster? [18:34] down to single digit and it'll just poll like mad for the length of the test [18:34] but it's a single one just to make sure the event it wired correctly [18:34] not even the whole suite of tests for that module need it, just the one test [18:34] hatch: yea, just off the top of my head [18:35] hatch: but yea, with a 50ms poll interval I had thought 4x as long would be good for this [18:36] so maybe it's not the case, but only thing I can think of that would case it to fail intermittantly [18:38] guihelp: when using firefox (testing against juju-core) if i'm on the service page and click on constraints attempting to go to http://localhost:8888/:gui:/service/mysql/constraints/ i then get trapped by the unsupported browser warning and then am shown the canvas. is this a new issue? === BradCrittenden is now known as bac [18:41] dumb question. no one has been able to do what i just described until the fix i just made...at least not with go juju [18:47] bac, can't get that to happen, but this is on improv [18:47] rick_h_: what tells the build script to include the widget files? [18:48] bac: no idea; I have a similar problem just double-clicking on a service [18:48] benji: that's the bug i'm working on [18:48] benji: you get a hang or browser trap? [18:48] bac: forever " [18:48] hatch: include the JS of them? or what [18:48] Loading..." [18:48] yah [18:49] hatch: they're added to the modules-debug right? [18:49] benji: yeah, that'll be fixed soon [18:49] yep [18:49] yay! [18:49] rick_h_: basically charm-search.js is not being loaded in prod tests [18:49] hatch: oh hmm. am I missing a YUI.use in that file? [18:49] * rick_h_ looks [18:50] I mean it works sometimes right? so wtf? [18:50] this is failing all the time [18:50] charm-search.js is not included in the all-yui.js [18:50] file [18:55] hatch: second, I've borked things up locally here atm [18:58] np take your time, we are taking a lunch break [18:59] lemme know when you're able to take a peek and I'll get you the branch and details [19:00] hatch: k, is there supposed to be something more to it? [19:00] than adding to modules-debug that is [19:02] hatch, your bug report about PyJujuAPI: same thing! works in debug, fails in prod, at least for me [19:02] lunch now ;-) [19:02] gary_poster: yep yep [19:03] rick_h_: setting describe.only() on browser search widget causes the tests to fail on sh test-server.sh prod true [19:03] Uncaught TypeError: Cannot read property 'widgets' of undefined [19:04] rick_h_: lp:~gary/juju-gui/testclean is the branch we are hacking on [19:04] now I'm lunching [19:04] :) [19:04] hatch: cool, will thanks [19:19] rick_h_: so, with the changes to the container, we're left a little unclear on behavior. i'm assuming clicking the little arrow expands and the arrow changes for "less"; does the num in parenthesis do anything? does it show the total, or how many more there are...? [19:19] https://codereview.appspot.com/8315046/ could use another review he says as he heads to lunch [19:19] jcsackett: we can check with luca and jovan (not in channel atm) but I assumed it just showed the total count of items [19:19] jcsackett: so it would not change [19:20] rick_h_: ok. [19:39] gary_poster: tests now done... [19:39] gary_poster: *now* for status :-) [19:40] rogpeppe, :-) awesome [19:40] gary_poster: even better, the new tests exposed a significant bug... [19:40] that does always feel good [19:40] gary_poster: in the new code [19:40] cool [19:46] hatch: when you get back let me know. Your branch lp:~gary/juju-gui/testclean works for test-prod for me, however I was working on lp:~rharding/juju-gui/event_tracker and that was throwing a buildCfg error creating the object definition on charm-search and I can't figure out why. [19:47] rick_h_, to provoke, you do the following: [19:47] ./test-server.sh prod true [19:47] then [19:47] http://localhost:8084/test/index.html?grep=sandbox.PyJujuAPI [19:47] and/or [19:48] http://localhost:8084/test/index.html?grep=browser%20search%20widget [19:48] gary_poster: cool thanks looking [19:50] rick_h_ and hatch: can y'all look at https://codereview.appspot.com/8488045/ [19:50] rick_h_: i didn't update the template for the design we have now in this branch; i did it in a follow up that's on rietveld, but has this one as a dependent. [19:56] back [19:56] gary_poster: so any ideas over lunch? :) [19:58] hatch: so the widgets are loaded as part of app.js, not yui-all.js [19:58] hatch: and that's never loaded in the test file links that gary_poster gave me [19:59] hatch: so maybe you can fill me in on the diff between the yui-all and app.js and how that works with tests? [19:59] sorry, missed the first ping [19:59] rick_h_, you have stumbled upon a mystery wrapped within an enigma...or at least something I've forgotten most of :-P [20:00] hatch: I can move widgets in modules-debug to their own category like the others loaded into app.js (things like the d3 and prettify are in yui-all.js) [20:01] but yea, I don't see tests loading app.js, I'm not sure atm how tests do work now that I see this lol [20:01] ahhh [20:01] so THAT's why it works when we load everything [20:01] s/load/run [20:01] hmm I really don't like that [20:01] well, but why is app.js loading when we run everything [20:02] yea, app.js is loaded when we run everything, looking to see 'who/why' [20:02] well because we instantiate it in test_app.js [20:02] instantiate? [20:02] the file? [20:02] thsi is in prod [20:02] so everything should be compressed [20:02] ohhh [20:02] yes [20:02] some other test/file/etc is loading app.js somehow I think [20:03] well but that shouldn't matter [20:03] fwiw, I verified that adding app.js to index.html makes everything better [20:03] hatch: so yea, I'm not sure, still working through this [20:04] because when we include the browser-search-widget module it should pull in everyuthing that it needs [20:04] I mean if app.js isn't in the tests how to the tests for everything juju.. work? [20:04] yeah exactly [20:04] hatch: well, it's not pulling in app.js. That's not a YUI module or the like [20:04] hatch: there's noting in the YUI system to pull/load that in [20:05] I mean http://localhost:8084/test/index.html?grep=juju%20unit%20view fails as well [20:06] because app.js isn't loaded and there's no such thing as Y.juju as far as the test is concerned [20:06] well that should be loaded in the tests that need it [20:06] maybe I'm totally missing what you're saying [20:06] app.js is not in modules hatch [20:06] guichat? [20:06] sec, I've got to get my headset and such [20:06] I'm there [20:15] * Makyo dogs-walk. === deryck[afk] is now known as deryck [20:17] thanks rick [20:20] is there any way to make lbox/rietveld play nice with pipes/prereq branches? [20:24] hatch: you guys still on? [20:24] yep [20:24] hatch: sorry, battery died on me mid-call [20:24] k, sec [20:24] jcsackett: -req=lp:.... flag [20:25] rick_h_: ah, ok. [20:25] thanks [20:36] jcsackett: cool thanks for the updates [20:36] rick_h_: yw. [20:44] rick_h_: the charm container/sidebar integration is up as well, as is the followup for the container design. [20:44] https://codereview.appspot.com/8529044/ and https://codereview.appspot.com/8529043/ [20:46] jcsackett: looking [20:49] jcsackett: ok, comments on everything [20:52] jcsackett: hatch if you guys get a sec: https://codereview.appspot.com/8491045 [20:52] hatch: ^^ is the event tracking extension to auto clean and applied in an initial set of uses [20:52] hatch: I could not find any way in YUI to track anytime someone did a xx.on() to auto catch them :( [20:53] hatch: so not sure it can go upstream, but maybe the 'idea' can. [20:53] and with that...I'm spent. phew [21:04] a find juju-core branch for review if anyone would like: https://codereview.appspot.com/8532043 [21:04] s/find/fine [21:05] * bac -> dogwalk [21:16] rick_h_: do we need to keep the _renderSlider thing? or, honestly, any of the slider code? [21:17] no I don't think so. [21:17] ok, i'm going to start another branch to kill it all. [21:17] jcsackett it'll just be another container [21:17] jcsackett :-( [21:25] hatch: can i trouble you for three short reviews? [21:26] three? wow hah [21:26] sure [21:27] hatch, awesome, thanks. they build on each other. https://codereview.appspot.com/8488045/ https://codereview.appspot.com/8529043/ and https://codereview.appspot.com/8529044/ [21:28] alright [21:28] he cheats with bzr pipes :-P [21:29] cheats nothing. i am *awesome* with bzr pipes. [21:41] * rogpeppe likes bzr pipes too [21:48] whats a bzr pipe? [21:52] jcsackett: reviews all done all LGTM with a couple questions on some [21:57] gary_poster: so that test is failing because 'scrollview-base-ie' is not being merged into the rollup any longer [22:08] hatch the slider and thus scroll view is going away [22:08] killed by UX. jcsackett just started a branch to remove it all [22:08] oh interesing, what's the ETA? We can't land this branch as-is because that test fails [22:09] hatch tomorrow [22:10] oh awesome, ok then I won't spend any time on debugging it [22:10] although maybe I should as this file 'should' be being able to be merged in [22:21] https://codereview.appspot.com/8315046/ could still use a second review [22:31] gary_poster: unit and machine status now done; just testing, then will propose [22:34] bcsaller: Ican do it before EOD [22:35] hatch: thanks [22:38] I wish it would tell me what in my deepEquals doesn't match [22:46] hatch: i sometime use github.com/davecgh/go-spew/spew [22:46] that 404'd [22:46] although I'm not sure something for go would help me with js :) [22:46] hatch: go get github.com/davecgh/go-spew/spew [22:47] hatch: ah! [22:47] hatch: i didn't know js had deepEquals [22:47] it's part of the assert lib [22:48] javascript has everything - it's just usually not included by default in the lang :) [22:48] thats why we have libraries [22:48] if anyone's waiting on UnitInfo.Status and MachineInfo.Status, i've got a branch proposed that adds them [22:48] and lots of them :D [22:48] https://codereview.appspot.com/8534043/ [22:48] hatch: :-) [22:48] i'm off now [22:48] night all [22:49] night! [22:52] bcsaller: you were saying I needed to try and do some subordinate relationship? [22:52] got a second to bring me up to speed on what that was about? [22:52] sure [22:52] guichat? [22:53] joining [22:58] hatch ah, cool. easy fix? back later [23:23] gary_poster: it should actually have already been fixed (see merge-files) for some reason that is no longer being considered. Although rich mentioned that jc is removing that scroll view tomorrow anyways so it won't actually be an issue...but we should still find out why that file isn't being included me thinks. [23:41] bcsaller: review done [23:42] hatch: thank you [23:43] going to take a break - I'll bbl to try and hammer our more of the relations stuff