[13:52] morning [13:52] hi hatch [13:54] rogpeppe: I am encountering 8 failures in juju-core trunk tests, all related to uniter_test.go [13:55] rogpeppe: and hi :-) [13:55] frankban: hiya [13:55] frankban: you're best raising this in juju-dev, i think. i'll just check that i see the same thing first though. [13:55] rogpeppe: thanks [13:56] Makyo: good morning, re annotations branch, we are almost there :-) [13:57] frankban, \o/ [13:57] I will need at least one more coffee before I can understand Go. [13:58] frankban: uniter tests pass for me in trunk [13:58] frankban: could you paste me your errors? [13:59] rogpeppe: trying, re-running the whole suite, failures include lots of debug messages [14:04] rogpeppe: http://pastebin.ubuntu.com/5625282/ [14:05] frankban: interesting. i'll pass it over to dimiter and william, who've been working on the uniter stuff [14:05] rogpeppe: thanks [14:09] rogpeppe, hi! Exciting seeing the allwatcher branches move through. On a mostly unrelated topic, we will want the GUI to expose upgrade charm from both pyjuju and juju-core. AFAIK it is not yet implemented at all in juju-core, even as a command. Am I right? If so, do you know who will be responsible for that implementation? I have some questions from the designers that I'd like to get answers for (http://paste [14:09] bin.ubuntu.com/5625286/) [14:10] gary_poster: in a meeting currently [14:10] rogpeppe, ack np [14:27] jujugui call in 2 in guichatr [14:28] guichat [14:30] gary_poster: my browser doesn't want to connect to the hangout; I'll be there as soon as possible [14:31] ack benji [14:35] gary_poster: dimitern is implementing charm upgrading. i think it's going pretty well [14:35] rogpeppe, great will ping him later [14:35] benji, how goes set_constraints [14:36] gary_poster: i'd still be interested in any comments you have on the allwatcher reviews, BTW. i'm going to be submitting https://codereview.appspot.com/7815044/ shortly, but if you want to take a look, i'll hold off for a while. [14:36] gary_poster: pretty good; once I figure out this import loop it should be smooth sailing [14:36] ok great thanks both [14:37] * benji reboots while giving the Google Hangouts plugin the evil eye. [14:41] frankban: i'm presuming you saw those uniter test failures on the latest version of trunk (1012) ? [14:42] rogpeppe: yes, running the suite again using 1013 [14:43] frankban: perhaps you could liaise with dimitern on #juju-dev to try to resolve this, as you seem to be able to reliable reproduce the issue. [14:43] frankban: i'm going for lunch now [14:43] rogpeppe: I will, thanks [14:46] hi, is this a known bug? http://i.imagebanana.com/img/2sphe691/Selection_001.png [14:46] the clutter, and the fact that there are no relations drawn === andreas__ is now known as ahasenack [14:47] if I drill down on a box (double click), the relation is displayed [14:51] ahasenack, Not seen that before. What browser and version of the gui? [14:52] Makyo: chrome, gui "stable" according to the charm [14:52] just deployed [14:52] guihelp ^^^ [14:52] Google Chrome 25.0.1364.172 (Official Build 187217) [14:52] ahasenack, Alright. Give me a sec take a look on my side real quick [14:54] ahasenack, never seen. Makyo thanks for looking. A URL for Makyo would help if you can share it ahasenack [14:55] gary_poster: I don't think I can, it's deep within a private network [14:55] ahasenack, ack [14:55] ahasenack, Is there anything in the JS console? Ctrl+Shift+J [14:55] Makyo: hm, yes [14:56] Makyo: http://pastebin.ubuntu.com/5625372/ [14:58] http://pastebin.ubuntu.com/5625378/ when I reload the page [14:58] ahasenack, Ah, thanks. [14:59] Makyo: I am thinking that might be caused by views/landscape.js ln 19 [14:59] * hatch grumbles because he can't get the IE tests to fail again [15:00] hatch, Yeah, that's the exception. Looks like we're passing undefined to it from getLandscapeURL, though. Digging into that. [15:02] landscape itself might be having problems in sending down some annotations, we have a bug open to track a traceback [15:04] ahasenack, Yeah. From the looks of it, the services do not have a landscape-computers annotation coming from juju (app/views/landscape.js:123 for those keeping track) which is causing the drawing of services to fail part-way through. There should be a check on that annotation in there as well. [15:06] Makyo: ok, so that is breaking the rendering [15:06] ahasenack, Yep. The services being cluttered is a separate issue, FWIW, but that is what's stopping the services from rendering completely with the health graphs, proper name placement, etc. [15:07] ok [15:10] Filed #1156662, will do a quick branch to at least add the check. [15:10] <_mup_> Bug #1156662: getLandscapeURL is not checking annotations on models other than environment < https://launchpad.net/bugs/1156662 > [15:11] Makyo: I wonder if we shouldn't notify the user that there is a problem? [15:12] Makyo: thanks [15:13] ahasenack, the services being cluttered is something that the user is supposed to be able to address by dragging them around. Not ideal, but workable, and only painful initially (the service locations are shared and persistent) [15:13] hatch, Yeah, we don't have any requirements yet around that story. Any suggestions, guihelp, ahasenack, goodspud? [15:13] alert('Landscape broked - tell boss'); [15:14] well, I will have to see how it looks when the rendering is complete [15:20] gary_poster: lp2kanban is having buildout issues. can you quickly diagnose it? https://pastebin.canonical.com/87040/ [15:20] Makyo: do we have a story for warnings in general? something akin to http://twitter.github.com/bootstrap/components.html#alerts [15:21] gary_poster: if not i'll dig into it in a bit, after getting my real branch re-proposed [15:21] bac afraid completely booked [15:21] gary_poster: ok, p [15:21] np [15:21] hatch, two: notifications and alert widgets (though the latter are generally used in a confirmation sense). [15:22] hatch, You can try removing a subordinate relation to see one used in a warning sense, though. [15:22] ahh ok - I wonder if it makes sense to use that type of warning? [15:23] hatch, Perhaps. While it's a good indicator that something's fairly wrong, we've been using notifications for something wrong with the data we've received. [15:24] ahhh yeah I suppose it's not an issue with the gui itself but with the data being received [15:26] ahasenack, Is a screenshot helpful? http://ubuntuone.com/3KzgiaR1qBqjWpv2Sj4D3r If you need more, I can see what I can do. [15:39] jcsackett: are you around? [15:42] rogpeppe: I have an import loop that I'm having problems solving; here is the diff that generates it: http://paste.ubuntu.com/5625502/ [15:42] Makyo: what is that screenshot about? That 1 alert? [15:43] benji: it might be worth compiling against go tip - the go tool should tell you what the import cycle is. [15:43] ahasenack, The completed rendering. [15:43] benji: if you don't want to, paste us the branch and i'll do it. [15:43] rogpeppe: any tips on how to install go tip? [15:43] ahasenack, I think he was replying to your "I will have to see how it looks when the rendering is complete." You'll want to see it in full QA of course [15:43] Makyo: ah, sure, it looks fine. I meant that I would have to see how mine looks, with so many units [15:44] ahasenack, Ah, okay. [15:44] ahasenack, how many services is that? [15:44] is installing tip reversable? will it lead to other problems working on go code if the others on the team aren't using tip? [15:44] and how hard it will/would be to unclutter it [15:44] gary_poster: 29 or so [15:44] benji: i install go tip inside $HOME/go; and yeah it's reversible by simply deleting that directory. [15:44] ahasenack, that's at the top limit of what we say we support. You should still be able to get it to work. Does that collection represent some real-world-ish use case? [15:45] rogpeppe: cool, is there a web page that describes how do do that? [15:45] benji: assuming you've got mercurial installed, hg clone https://code.google.com/p/go/; cd go/src; ./all.bash [15:45] gary_poster: yes [15:45] benji: should do the trick [15:45] benji: one mo, i'll look [15:45] rogpeppe: cool, I'll give it a try [15:45] ahasenack, cool. Do you mind telling me what the use case is? It would be good for us to document a real world use case of that size [15:46] gary_poster: openstack deployment [15:46] benji: you *might* have to do 'hg update tip' before building [15:46] benji: oh yes, you'll need to set $GOROOT to the root of the go source tree [15:47] ah [15:47] ahasenack, wow! I thought that was under 10. Maybe once you have that running with proper rendering I can ask you for a screen shot so I can see how they all interconnect. [15:47] benji: i regularly use two copies of go root - one running 1.0.2, one running tip [15:47] gary_poster: yeah, I have more than one unit per service here [15:48] benji: here's the shell script i use for switching to use 1.0.2 http://paste.ubuntu.com/5625516/ [15:48] ahasenack, you use multiple units within a service [15:48] gary_poster: like 4 compute nodes, for example [15:48] cool [15:48] benji: it's worth having a separate GOPATH to use with the separate go version, i think. [15:48] ahasenack, so unless there's something unusual with what you are doing, the compute node should be a single service [15:48] ahasenack, with 4 units [15:49] gary_poster: and each unit is one computer [15:49] ahasenack, yes [15:49] openstack has many services [15:49] benji: i generally develop against tip and test against 1.0.2 before proposing (or when i want to run tests while i'm switched to another branch) [15:50] ahasenack, right but < 10 yeah? [15:50] Makyo: ping [15:50] benji: ah, here are the official installation instructions: http://golang.org/doc/install/source [15:50] benji: they basically amount to what i said, i think [15:50] frankban, Hey [15:50] then if you expand them out, you expand them *within* the services. Am I missing something basic about what you are doing? Should we have a call instead? [15:50] rogpeppe: thanks, that looks helpful [15:50] Makyo: could you please branch lp:~frankban/juju-core/ann-doc/ and check all tests pass? [15:51] frankban, yep, on it. [15:51] let's see, compute, quantum, dashboard, keystone, rabbit, ceph, cinder, glance, juju-gui, mysql, cloud-controller, swift-proxy, swift-storage [15:52] ahasenack, ok cool, 13 is still in my rough mental model :-) [15:52] :) [15:52] juju-gui not strictly being openstack, I was just going over juju status [15:53] ahasenack, ah, cool! so you have 13 services, using 29 machines using some distribution or other? [15:53] Makyo: thanks [15:53] I mean, a distribution so that compute nodes have 4 machines, and dashboard gets 1, and so on [15:54] gary_poster: yes, most have more than one unit [15:54] otherwise it wouldn't be fun, that's the power of juju [15:54] I also have landscape-client on each unit as a subordinate [15:55] ahasenack, cool, ok. agreed. 13 services--ok, right, 14 with Landscape-- shouldn't be too bad to arrange at all. We have something like that for our own demos. If you arrange it before the demo it can even look pretty when the audience sees it. :-) [15:55] :) [15:56] thanks ahasenack. so your work is done until Landscape engineers add the missing annotation, right? [15:56] I mean the work for QAing this, of course :-) [15:56] gary_poster: yes, in fact I have a workaround to try in landscape that someone just gave me, I'm about to try that [15:56] ahasenack, excellent! [15:58] gary_poster: thanks for the help [15:58] ahasenack, np, thank you [16:06] so our city had a massive watermain break Friday which caused the city to issue a 'boil water' warning - no big deal except that all of the coffee shops are shut down because the water in their machines is piped right in from the city water [16:13] frankban, Everything but uniter_tests.go passes. [16:13] Makyo: could you please try the same in the master branch (most recent trunk)? [16:13] frankban, yep. [16:14] Makyo: thanks again. [16:15] w00t w00t - found the CI issue [16:15] * hatch does the happy dance [16:16] http://www.hblewett.com/blog/wp-content/uploads/2011/06/Snoopy-Happy-Dance.jpg [16:20] hatch: cool! what was the problem? [16:20] frankban, same failures in trunk. [16:20] Makyo: :-/ 8 failures? [16:21] frankban: missing dependencies which would be auto resolved on our local machines [16:21] ben and I are looking into the solution now [16:21] frankban, Yep. [16:21] rogpeppe: I have go version devel +43eb97ed849a but am still getting the standard terse import cycle error. Is there a switch I have to throw to get more info? [16:22] benji: hmm. it might depend where in the import cycle you're compiling :-| [16:23] * benji laughs an acidic laugh. [16:23] benji: beforehand i remember sometimes not being shown the cycle, but i can't remember when or why [16:23] benji: could you push your branch and i'll take a look? [16:25] benji: when i add the state import to api/params, i see this: [16:25] can't load package: package launchpad.net/juju-core/state/api/params [16:25] imports launchpad.net/juju-core/state [16:25] imports launchpad.net/juju-core/state/api/params: import cycle not allowed [16:26] benji: so i see where your problem is now [16:27] Makyo: can you confirm tests in state/. pass? [16:27] Makyo: (in the ann branch) [16:28] benji: ok, i have a solution for you [16:29] frankban, Yeah, they pass. [16:30] ok, Makyo: maybe it's time for some pairing, let's use termbeamer, what's your jabber/gtalk account? could you add me please? [16:31] Makyo: mine is frankban@gmail.com [16:32] frankban, drab.makyo@gmail.com [16:35] benji: suggestion: from the juju-core root: mkdir constraints; bzr mv state/constraints*.go constraints; fix everything in state to import the new package and use constraints.Constraints not state.Constraints. [16:38] benji: modification: as above, but rename Constraints to Value along the way. [17:04] benji: ping === matsubara is now known as matsubara-lunch [17:15] rogpeppe: (I was eating lunch while you guys figured that out.) cool, thanks [17:16] benji: ah, i wondered [17:16] benji: np. does that seem reasonable? [17:17] rogpeppe: yep I think it's reasonable; if I find out otherwise I'll be sure to let you know ;) [17:17] benji: :-) [17:25] jujugui if anyone has a moment for a 5 line diff review :) https://codereview.appspot.com/7621045/ [17:26] hatch: I do [17:26] thanks [17:28] gary_poster: http://stackoverflow.com/questions/14801416/zc-buildout-stopped-working-importerror-no-module-named-apport-fileutils << this was the problem [17:29] ack bac. sorry it took time [17:39] gary_poster: remember when I was saying guys can get huge air kiteboarding? This takes it to a whole other level http://www.youtube.com/watch?v=3JWi78hk8oQ :) [17:39] hatch, :-) cool will look in a few [17:42] * benji enjoys the very exciting thunderstorm going on here. [17:47] gary_poster: the workaround worked, I see the relations drawn in the juju-gui "picture" now. I'll look for the landscape stuff now [17:48] great ahasenack! If you don't see "Landscape" logo in the bottom right then it's not showing up. It's pretty obvious. [17:48] gary_poster: I see it [17:48] oh, great [17:48] gary_poster: aren't the words reversed? [17:48] gary_poster: I read "environment\nlandscape" [17:49] ahasenack, not clear what you mean yet, sorry. screenshot? Or maybe the one Matt gave earlier could be used to make your point? [17:49] * gary_poster has to go back to other computer to find the image [17:49] gary_poster: I mean, I would say "Landscape Environment", not "Environment Landscape" === deryck is now known as deryck[lunch] [17:52] ahasenack, Landscape is not the environment...I think I know what you mean (from memory; not looking atm). That is the link to the environment information within landscape--the information about the environment that landscape knows about. If you double click on a service (or single click -> "View") then you will see that show as "Service" [17:52] ahasenack, this is good feedback for our design people though. Would it be too much to ask for an email about the things that confused you? [17:53] The "Landscape" text is just indicating that this is Landscape-specific information [17:53] gary_poster: I know, it's a link to the juju environment in landscape [17:53] hatch, that's pretty insane :-) [17:54] Haha especially considering those kites are designed to fly lol [17:54] hatch, not designed to, you mean,right? [17:55] gary_poster: isn't it better to file a bug? It can be closed if they don't agree [17:55] I do find that wording incorrect, though: "environment LANDSCAPE" [17:55] makes no sense :) [17:55] gary_poster: oh yeah, definitely -not- [17:55] :) [17:56] ahasenack, +1. I would fill the bug out for you, but I don't understand the position yet--perhaps stared at this too much :-) [17:56] so your explanation--why it seems obviously incorrect--would be valuable [17:56] gary_poster: bottom-right corner: http://i.imagebanana.com/img/wq182eee/Selection_001.png [17:57] cool ahasenack, right, thx. [17:57] gary_poster: bug coming up [17:57] great [17:58] hatch did that IE fix make everything better, or just was incremental improvement? [17:59] Ben is still working on the timeout bug but this should fix the IE bugs - I'm just about to trigger another build to test [18:10] rogpeppe: Moving the Constraint.Value methods won't work because they take state.State arguments, inducing a new import cycle. Should I just move the data type only and leave the methods in the state package? [18:10] benji: looking [18:11] benji: i think those functions (create, read and writeConstraints) should remain in state, as they're directly to do with mongo interactions [18:12] benji: the Constraints type and its methods can (i think!) move ok [18:12] rogpeppe: makes sense, thanks [18:12] benji: in fact, everything from 'type constraintsDoc' onwards should remain in state [18:12] k === matsubara-lunch is now known as matsubara [18:18] bcsaller__: it looks like the sauce labs IE instance is caching stuff - this last run had the same issue we see if we don't clear IE's cache [18:19] hatch: I saw that on Thursday as well. It didn't make sense as it should be a new VM but they might go through a caching proxy [18:19] yep - well I'm going to grab some lunch and then I'll investigate this when I get back [18:19] just wanted to let you know where it left off [18:21] before I go - anyone know how to make a newline on the wiki? [18:22] hatch, new lines, I think? :-) [18:24] the go import system leaves something to be desired; a name like "constraints.Value" makes sense for all packages except the one in which it is defined (where it is simply named "Value" which is somewhat informationless). [18:25] I guess that's the same problem that the Python import system has; I wonder why I don't remember tripping over it there; different naming conventions perhaps? [18:26] gary_poster: hah I tried that, I ended up just putting a line between the other lines....double space :) [18:29] gary_poster: next branch here - in the next branch we'll actually hook it up to the API! https://codereview.appspot.com/7650048 [18:33] hatch, heh. I [18:33] 'll look at it if you want. [18:33] rogpeppe, awesome! [18:59] guihelp: anyone have a moment for a review? https://codereview.appspot.com/7871044 [18:59] Yep [18:59] bac, on it [18:59] bac, On it. [18:59] Too late! [18:59] :-) [19:00] wow! such enthusiasm [19:00] i love that we had a bug where we try to beautify prettify.js [19:01] :-) [19:01] or, better that prettify needs beautifying [19:04] bac LGTM with trivial [19:04] thanks gary_poster [19:06] benji did you get unblocked with circular import? [19:06] gary_poster: yep; I just had a 100% passing full test run; now I just have to write the code to do the actual thing the branch is supposed to do ;) [19:07] benji, heh, cool-ish ;-) [19:07] I'm contemplating posting the branch as-is for review. (The combination of cobzr and lbox make me shudder at the thought though.) [19:07] :-) [19:08] hatch: i've got to pass a context, and since it isn't used we decided a week or so ago that null was a pretty good choice. [19:08] hatch: is there a better option? [19:08] sorry - I meant to say, why do you need to pass a context at all [19:08] why can't you just call the method? [19:09] he's making a partial without making a closure [19:09] i'm using Y.bind to curry the values of the other params [19:09] yeah, that [19:09] yeah, that [19:10] oh ok then - could you comment as such? That's not a very common pattern so someone may come by and remove that in the future :) [19:10] hatch, what's the way you would have done that? [19:11] closure? [19:11] yeah I would have done a closure - but I'm going to guess that this method does need to be called externally at some point? [19:12] nope [19:12] just trying to keep code divided up nicely [19:12] you could still do that with a closure [19:12] wrapping the other function === deryck[lunch] is now known as deryck [19:14] this._send_rpc(..., function(data) {this.handleRemoveRelation(callback, endpoint_a, endpoint_b, data); }) [19:14] hatch: that function is commented as: // Curry the endpoints. No context is passed. [19:14] damn [19:14] and, it is a common practice. i did it 8 times in that one module. :) [19:14] * hatch bows his head in shame [19:14] lol [19:15] hatch, why? [19:15] gary_poster: are you proposing that change? [19:15] bac, no. you'd have to push the if in there too [19:15] or something [19:15] I read the comment and it didn't click :) [19:15] oh :-) [19:15] ok then just change the names to camelCase :P [19:15] heh [19:15] this is legacy support [19:16] hatch: as to the camel case, the existing call sites use endpoint_a and endpoint_b. i'd rather not make the change and have a mismatch [19:16] we need to do a mass remove_relation -> removerRelation [19:16] removeRelation [19:16] which we can do [19:16] OK FINE!!!! [19:16] :P [19:16] but separately :-) [19:16] remove_relation -> destroyRelation [19:16] lol [19:16] heh [19:16] I'll put LGTM on it [19:16] :) [19:16] :-) [19:17] destroy is the canonical name. remove is an alias. [19:17] sorry for weighing in. I think I might be procrastinating. [19:17] haha [19:18] bcsaller__: ok now that all the tests pass in the CI it's all good but for some reason it's still timing out even though it hits 100% then just sits there [19:19] I think we need a 'complete' flag or something [19:19] hatch: you're not seeing a request to login in the video? Thats why the timeout [19:20] nope - it's just sitting here until the timeout hits [19:20] gotcha - that's the part you were mentioning about earlier [19:21] so is there anything else that I should be doing on this? Or is the rest in your wheelhouse? [19:23] hatch: I think I can handle the last step [19:23] ok great - I'll finish up these CI docs then - lemme know if you want to bounce any ideas around [20:00] jujugui I need one more review for the CI documentation https://codereview.appspot.com/7678048/ anyone have a few minutes? [20:00] * gary_poster did first one :-) [20:01] hatch, sure. [20:01] * BradCrittenden dang [20:01] thanks === BradCrittenden is now known as bac [20:01] Hah! [20:03] hatch, I'm going to try to give you a patch to hook up with docs, gimme a bit [20:06] interactive testing of the go api with firefox is a real pain...but very gratifying when it works [20:12] hatch if you apply http://paste.ubuntu.com/5626260/ (in particular the docs/index.rst change) then you will be able to run make view-docs and go to the new doc from the (non-YUI) index page [20:13] oops [20:17] * benji wades through 2,154 lines of test runner output. [20:17] * gary_poster , knowing benji, knows that this is not hyperbole [20:21] gary_poster: sure I'll make these changes then run the make [20:21] * bac dogwalk [20:22] cool hatch. The only point of running the make is to show you that it works generally, works specifically with your new file, and might be useful. :-) [20:22] * benji wishes it were. [20:23] The whole "hey one of your tests failed, here is the unrelated output of everything that has ever been logged in the history of the universe; you're welcome" thing is not so great [20:24] heh [20:25] gary_poster: that worked well - the docs actually look pretty good *brushes shoulder like a boss* [20:26] hatch, they do :-) [20:26] haha [20:28] ok changes have been pushed