[01:45] goyaml seems to have some issues with go 1.1 http://paste.ubuntu.com/5663122/ [01:52] argh... nevermind some sort of GOPATH wierdness was picking up a GOROOT value [01:52] re goyaml === racedo` is now known as racedo [08:14] yay! internet is finally back on! [08:18] they don't want to delay the propagation of Go 1.1 ;-) [09:46] rogpeppe, how much experience do you have running benchmarks in gocheck? [09:47] mattyw: i've done a few [09:48] rogpeppe, I've got two packages with benchmarks in them, but I don't seem to be able to run all of them at once (in one command) [09:48] mattyw: go test -gocheck.b should do it [09:50] rogpeppe, it doesn't seem to, although it's just occured to me that it might be my tree that's causing it. I've got benchmarks in juju/ws/ws_test.go and juju/api/api_test.go but no tests in juju [09:50] mattyw: what directory are you running the tests in? [09:51] rogpeppe, well I have to be in juju/api or juju/ws as there aren't any tests higher up [09:51] mattyw: what do you see if you do go test -gocheck.b -gocheck.v ? [09:52] rogpeppe, it's only running the api test if I'm in the api package when I run the command [09:53] rogpeppe, I guess this sort of makes sense [09:55] mattyw: go test only tests the package in the current directory by default [09:55] mattyw: you can give it a list of packages if you want [09:55] mattyw: or a wildcard (see "go help packages" for some docs on that) [09:57] rogpeppe, but if I'm supplying -gocheck.b I need to do that from within a package wich has a gocheck test it looks like [09:57] mattyw: yes [09:57] mattyw: most packages do, but not quite all unfortunately [09:59] rogpeppe, so if I wanted to run all the benchmarks in my codebase by doing go test -gocheck.b launchpad.net/thing/foo/... launchpad.net/thing/bar/... I need to have a gocheck package in my current dir? [09:59] mattyw: no [09:59] rogpeppe, (jet lag is probably causing me to not be making much sense) [09:59] mattyw: just in the packages that you're testing [09:59] mattyw: you can see which packages match by using go list [10:00] rogpeppe, would a quick hangout be possible? might be quicker for you to see what I'm talking about [10:00] mattyw: sure [10:00] rogpeppe, thanks very much https://plus.google.com/hangouts/_/6fabced08041ffc4a35b6ebdd200962be8e826ba === wedgwood_away is now known as wedgwood === marcoceppi_ is now known as marcoceppi === meetingology` is now known as meetingology === _mup__ is now known as _mup_ [14:54] rogpeppe2, the provider port opening for the api is generic or is it per provider? [14:55] hazmat: in the api, it's generic (it just sets the flag in the state). the firewaller agent is responsible for acting on that state change, and each provider implements port opening privately. [14:56] rogpeppe2, i've been seeing some issues with client connectivity to the api in openstack environments, just trying to debug.. it works on localhost but remotely it generates an http 400 server error [14:57] i suspect its something to do with the origin header on the websocket [14:57] works ootb on ec2 [14:57] hazmat: hmm odd. [14:58] hazmat: could it be something to do with limited public ip address space? [14:59] rogpeppe2, its happened on canonistack and hpcloud [14:59] hazmat: you're getting a 400 server error from the API? or from the service you've deployed? [14:59] in the canonistack case the user had sshuttle setup as transparent proxy [14:59] rogpeppe2, api server [15:00] hazmat: through the GUI or direct? [15:00] rogpeppe2, direct [15:00] hazmat: what's the full body of the error? [15:01] rogpeppe2, nothing in the juju logs, its silent.. looks like pre login nothing gets logged there [15:01] hazmat: i meant of the 400 error. [15:01] rogpeppe2, empty body [15:01] hazmat: i'm wondering if the error is coming from the API server or something else [15:01] hazmat: and "400 server error" is the whole text of the error? [15:02] * hazmat setups a reproduce csae [15:06] rogpeppe2, so this is out of the box on hpcloud.. generates a 403.. http://pastebin.ubuntu.com/5664742/ [15:06] hazmat: ah, "forbidden". hmm. [15:07] rogpeppe2, if i setup the client on the localhost there i can get it to work [15:07] hazmat: is that a public ip address i could try ? [15:07] rogpeppe2, that is a public ip address [15:07] rogpeppe2, i'll import your key [15:08] rogpeppe2, you can ssh into the instance as well / u=ubuntu [15:10] rogpeppe2, the agent logs are useless since there isn't anything logged till post login afaics [15:10] rogpeppe2, i suspect its something in go.net websocket lib that's barfing [15:10] hazmat: it may be. i'm just writing a little bit of test code. [15:11] hazmat: i'm wondering if it's something to do with the "localhost" in this line: [15:11] cfg, err := websocket.NewConfig("wss://"+info.Addrs[0]+"/", "http://localhost/") [15:11] rogpeppe2, the odd bit, is that there is no '403' in that package [15:11] hmm [15:11] yes [15:11] that might be it [15:12] but no [15:12] but we use the address that the instance thinks it has so ... [15:12] hazmat: that's the client-side code [15:13] oh, not likely relevant then [15:13] rogpeppe2, got it... [15:13] its the go.net websocket server.go around the handshake [15:14] line 41-43 [15:15] hazmat: hmm, my line 41 says "config.Protocol = nil" [15:16] rogpeppe2, revision 49? of go.net [15:17] rogpeppe2, of websocket/server.go ? [15:17] hazmat: ah, i'm on r48 [15:18] hazmat: it's changed quite a bi [15:18] t [15:19] pity it discards the actual text of the error [15:20] rogpeppe2, so it looks like its the checkOrigin func of the handler [15:21] but that's a guess [15:22] hazmat: yes it looks like that [15:22] rogpeppe2, 2013/05/14 15:01:32 INFO environs/openstack: closed ports in security group juju-hp-0: [tcp:17070] [15:22] probably not relevant [15:23] the env group port is still open [15:23] that was juju correcting my manual changes [15:25] hazmat: hmm, it might have been rev 49 that broke it - it's a recent change with some relevant looking stuff [15:27] hazmat: are you using the release version of juju? [15:27] rogpeppe2, no.. there are other issues with that [15:27] hazmat: can you try with r48 of websocket? [15:27] rogpeppe2, i just see it re-jigging the origin parsing [15:28] rogpeppe2, but as per the content dump its present in the request [15:28] rogpeppe2, i'll add some debugging prints and redeploy it [15:29] hazmat: it looks like you'd get that result if the origin couldn't be parsed [15:29] rogpeppe2, hmm that could be it [15:29] rogpeppe2, yeah its the port number there [15:30] and the delta between 48/49 on origin parsing [15:30] hazmat: there's a port number in the origin? [15:30] rogpeppe2, per my pastebin yes [15:31] let me modify the client and see what happens [15:31] hazmat: ah! [15:31] hazmat: so it's all your fault :-) [15:31] rogpeppe2, debatable :-) [15:32] rogpeppe2, as in this case i didn't write the websocket client lib, and it did previously work against juju-core [15:33] and its still not identified as the actual bug [15:33] hazmat: oh yes [15:34] hazmat: Origin should be a url [15:34] rogpeppe2, its not the issue [15:34] hazmat: it's nothing to do with the port number [15:35] * hazmat plays around with url.Parse [15:36] jeeze this is inpenetrable http://tools.ietf.org/id/draft-abarth-origin-03.html [15:36] hazmat: here's a start: http://paste.ubuntu.com/5664817/ [15:37] rogpeppe2, do you get an err with that? [15:37] hazmat: yes [15:37] i just switched out to 1.1 [15:37] rogpeppe2, this might be a delta with go 1.0 [15:38] hazmat: i doubt it [15:38] hazmat: looks like that websocket update to me [15:38] rogpeppe2, ah yes.. ic [15:39] previously it only parsed with url if didn't match 13 or 8 on websocket protocol [15:40] by my shallow reading of http://tools.ietf.org/id/draft-abarth-origin-03.html it looks like your client is wrong [15:41] serialized-origin = scheme "://" host [ ":" port ] [15:43] rogpeppe2, depends .. looking at the websocket spec.. its not clear that's it meaningful.. the client can fake whatever they want.. so the server checking here is mostly just of the obnoxious broken sort. [15:43] http://learnitcorrect.com/blog/websocket-is-great-but-not-the-origin-policy.html [15:43] hazmat: i'm with you that the origin header is fundamentally weird and probably broken [15:44] hazmat: but that doesn't mean that the websocket code isn't correct to check it for syntactic correctness [15:44] rogpeppe2, the checking is also optional [15:44] what broke is the changing from optional to required [15:46] hazmat: yeah [15:46] hazmat: looks like i can get around it easily though [15:46] rogpeppe2, thanks for debugging with me [15:46] i'll workaround in the client [15:46] hazmat: by creating websocket.Server rather than using websocket.Handler directly [15:47] hazmat: and using a nil handshake function [15:47] rogpeppe2, yeah.. i was wondering why you were doing it that way.. ie not using most of the stuff in the server.go [15:47] hazmat: all that stuff is new [15:47] ah [15:47] hazmat: with r48 [15:47] hazmat: sorry, 49 [15:48] hazmat: i wonder if the default is wrong. who gives a f*** about Origin? [15:49] rogpeppe2, or more to the point, it looks like its there as a policy hook point for people that provider custom handshakes that do care.. just to avoid them having to do the origin parse themselves, as is its mostly useless though [15:50] hazmat: yeah. it's a pity that the default is to do a meaningless check on a header that noone cares about though. [15:50] rogpeppe2, revno 51.. summary: go.net/websocket: fix handshake error. [15:51] rogpeppe2, agreed [15:51] rogpeppe2, or even if they cared about is trivially faked [15:51] hazmat: i'm not sure r51 fixes the issue we're seeing here. [15:51] rogpeppe2, it doesn't [15:52] hazmat: i think the point is to avoid hoaxing people using normal browsers [15:52] hazmat: because you can't fake it from js [15:52] hazmat: i may be wrong though. it always seemed odd to me. [16:05] rogpeppe2, released new client versions w/ workaround/proper origin, thanks again [16:05] hazmat: np. i learned something new :-) [16:06] hazmat: i think i'll change the server to ignore the origin explicitly [17:06] Anybody going to the virtual UDS Juju Core session at 19:05 UTC? [17:06] http://summit.ubuntu.com/uds-1305/meeting/21818/juju-core-development/ [17:06] I will be there, but would appreciate help from anybody from core or blue that can attend. [17:20] mramm: i'm out i'm afraid [17:20] mramm: just leaving now [17:20] rogpeppe2: understood [17:20] just putting it out there ;) [17:20] mramm: i finally have internet back BTW [17:21] rogpeppe2: awesome! [17:21] mramm: lots of ancient lead wiring replaced apparently [17:21] mramm: so my connection may get faster [17:21] mramm: (takes 5-6 days to ramp up they said) [17:22] rogpeppe2: that is interesting [17:23] rogpeppe2: strange but interesting [17:23] mramm: apparently there *is* a button they can push to say "we know we just replaced the cable, so try the faster speed now" but they're not allowed to use it. [17:24] rogpeppe2: interesting [17:25] g'night all === deryck is now known as deryck[lunch] [18:32] Hi -- is this a known issue? Am I doing something wrong? var/lib/go/src/launchpad.net/juju-core/environs/openstack/provider.go:547: undefined: identity.AuthKeyPair (during go install -v launchpad.net/juju-core/...) [18:33] dpb1: I have not seen it, but perhaps davecheney will know more than me [18:37] seems like a version mismatch between juju-core and goose (the openstack API library) [18:47] * davecheney pricks up his ears [18:47] i'm not really here (waiting for a flight) [18:47] but I can try to help [18:54] davecheney, mramm: if you need me to try something out, let me know === deryck[lunch] is now known as deryck [19:00] interesting... go get is pulling in old bits for goose. /me looks into why [19:01] dpb1: the simplest way to fix this is [19:01] rm -rf $GOPATH/src/launchpad.net/goose [19:01] ok. [19:01] go get -u -v launchpad.net/juju-core/.... [19:02] there are more complicated explanations [19:02] but this one will get you going [19:02] * dpb1 tries [19:06] davecheney: awesome. that is working. I see the parent branch changed locations. I guess go doesn't better deal with that? [19:09] the support for bzr in the go tool is best effort [19:09] we've moved the bloody project that many times [19:09] maybe it would be easier to update the instructions to not use the go tool, and just tell people which packages to branch [19:11] davecheney: it is nice to bootstrap. about as dead simple as I have ever seen a project. :) [19:12] i don't think we (at canonical) are paying enough attention to what happens when we move projects around [19:12] i'll add some words to the README [19:12] k [19:12] thx, enjoy your flight. :) [19:13] dpb1: email me, david.cheney@canonical.com if you get stuck again [19:14] davecheney: sure thing === wedgwood is now known as wedgwood_away