[00:50] davecheney: looks like there was no release last week? [00:53] wallyworld: working on it now [00:53] it's an uphill battle [00:53] ok, good luck [01:11] axw: BONJOUR! [01:11] davecheney: hey :) [01:12] isn't it a bit early in the year to see you in this channel ? [01:12] nope, I start today [01:12] just getting my SSO setup now [01:13] davecheney: I'm not sure there's any consensus yet on the tls thing, did you have a preference? [01:13] will prob have to wait for EU to start to get more attention [01:14] bigjools: how horrible is it for use to carry this patch against golang package? [01:15] bigjools: instead of forking individual packages? [01:15] thumper: won't work on other platforms [01:15] what won't? [01:15] bigjools: if you've been able to fork those packages [01:15] then go with that [01:15] oh... like windows :) [01:15] we have no control over golang on non-Ubuntu [01:15] rog and I thought it would be more work [01:15] good to hear it was only 3 packages [01:16] well, I am a little concerned about forking net/http [01:16] davecheney: so you saying we fork the golang source? [01:16] axw: hello there, are you the new perth bod? [01:16] wallyworld: make private copies of a few packages [01:16] bigjools: ack [01:16] thumper: Hi. I surely am [01:16] axw: welcome [01:16] davecheney: won't that be a maintenance nightmare? [01:16] since net/http is likely to get a lot of changes in core [01:16] wallyworld: rock, meet hard place [01:16] please see the discussion on the mailing list [01:16] giving us a higher maintenance burden [01:16] wallyworld: hopefully not too hard [01:16] but yes [01:16] g'day axw, welcome to the fray [01:16] thumper: thanks! Looking forward to working with you guys [01:17] bigjools: thanks and hello [01:17] davecheney: i read it, and still think it sucks to fork go [01:17] * thumper is currently writing a depressing email [01:17] wallyworld: we aren't forking all of go [01:17] wallyworld: just three packages [01:17] axw: g'day from another aussie [01:17] thumper: still, 3 is 3 too many [01:18] wallyworld: please read the mailng list before commenting further [01:18] wallyworld: agreed, but in the perfect world, it would be fixed in core [01:18] i don't think anyone is happy about this situatoin [01:18] davecheney: i have [01:18] wallyworld: Hi :) [01:18] wallyworld: we all agree it is sub-optimal [01:18] do we know why there's resistance to accepting in the core Go? [01:18] but the best option out of a collection of shitty options [01:19] axw: you follow cricket? if so, ignore bigjools. he is an aussie now but still yearns for the shitty place he left behind for a new life [01:19] bigjools: no, please read my response on the mailinglist [01:19] wallyworld: I was about to ask if you'd enjoyed that yesterday [01:19] don't read too much into what agl wrote [01:19] wallyworld: heh :) sorry, can't say that I do [01:19] it was a throw away line [01:19] bigjools: FO [01:19] :) [01:20] davecheney: so you think there's a chance? [01:20] bigjools: yes [01:20] bigjools: even if so, won't come fast enough [01:21] but it won't be available til dec at the soonest [01:21] well if we know it's going to be in the next version, that's fine if it makes the next LTS, because the maintenance burden is not too bad [01:23] thumper: you available for a chat even though you're out and about? [01:23] https://t.co/ycH9kpo7ZH [01:24] wallyworld: hangout wouldn't really work in this café [01:24] irc is fine [01:24] will be home in an hour (ish) [01:25] thumper: so, i've been reading martin's branches. looks like there's agreement they can be landed. what do you need from an lxc perspective? [01:25] wallyworld: let me send this email, then we can talk more [01:26] looks like they handle more the non container side of things [01:26] ok [01:26] * wallyworld has some food [01:27] email sent [01:27] wallyworld: I've not looked at mgz's latest assuming he put some up on Friday [01:27] I should do soon [01:28] from what we talked about, the planned changes should be sufficient for the local provider [01:28] ok. there's 2 branches there [01:29] and some empty methods on ec2 etc that need implementing [01:29] davecheney: after 1.2 is released, how long will 1.1 be supported? [01:29] * thumper clicks [01:30] wallyworld: I was hoping someone would say to me about my tools branch: we should have tools.Tools not agent.Tools [01:30] but no... [01:30] perhaps I'll talk to fwreade about this again [01:30] ugh... [01:30] tools.Tools sounds better for sure [01:30] this table is mildly sticky [01:31] wallyworld: also tools package can be very targetted [01:31] in what it does [01:31] yes [01:31] bigjools: yes [01:31] maybe, agent/tools ? [01:31] not sure [01:31] 1.1 will not be supported [01:31] davecheney: so there's no crossover period at all? [01:32] well, not supported any more than 1.0 is supported [01:32] bigjools: there is [01:32] but the answer will always be, upgrade [01:32] that's really hostile to distros [01:32] I'm fairly sure, but importing agent/tools in no way implies bringing in agent [01:32] davecheney: right? [01:32] thumper: right what ? [01:32] the line above [01:32] thumper: if the tools sub package only relevant to agent? [01:32] is [01:33] wallyworld: it is only used by agents, and generated for the use of agents [01:33] so agent/tools perhaps [01:33] that is what I was thinking [01:33] thumper: that is correct, importing a/b/c in no way implies you are importing a/b [01:33] wallyworld: then we could keep the agent.Conf in agent [01:33] davecheney: ta [01:34] bigjools: i agree, i don't think it is something I am in a position to change [01:34] wallyworld: as agent/config was an attempt to show how horrible it is :) [01:34] yes [01:34] wallyworld: I don't really want to land that branch [01:34] I have suggested maintaing a stable branch [01:34] but the proposal was not accepted [01:34] davecheney: wow :( [01:34] davecheney: for golang? [01:34] thumper: yes [01:34] double wow [01:35] this chimes perfectly with the lack of versioning in dependencies - just use trunk folks! [01:35] \o/ WINNING! [01:35] * bigjools wonders how Google handles this [01:35] where did I put that tiger blood [01:36] bigjools: I bet they have their own tool chain around it [01:36] bigjools: they have all their source in one big perforce repo [01:36] davecheney: to those golang folks know anything about collaborative software development across multiple teams etc? seems not :-( [01:36] it's called /google [01:36] a while arse guess is that they maintain their own go versions too [01:36] do [01:36] I used to use Perforce years ago [01:37] thumper: the development is on golang.org [01:37] i think they may merge back to their /google mega repo [01:38] but that is just to fit their process [01:38] to the best of my knowledge there is no 'private' version of Go [01:38] can I build a lp recipe from a tag ? [01:39] good question [01:39] probably [01:39] bigjools: should I branch from the tag? it looks like lp recipes are happiest with branches [01:39] ok, i'll do that then [01:39] oh ffs [01:39] that'll mean pushing to the bot [01:39] that means I have to ask mgz to do it for me [01:39] because, reasons [01:39] the revision spec is defined in the recipe [01:39] so you can set what you like [01:40] why would you want a recipe for a fixed revision though? [01:40] davecheney: I *think* you can specify a revision spec in a recipe [01:40] davecheney: and if so, yes you can use a tag [01:40] https://help.launchpad.net/Packaging/SourceBuilds/Recipes#Specifying_the_branches [01:41] davecheney: see the specifying revisions [01:41] merge packaging lp:~bzr/bzr/packaging revno:2355 [01:41] lp:bzr tag:2.0 etc [01:42] thumper: fuckin' hot sauce [01:49] davecheney: why would you want a recipe for a fixed revision though? [01:50] bigjools: because I'm still doing the releases without my big boy pants on [01:51] * bigjools tries to unsee and fails [01:51] bigjools: right now the recipe builds the debs which I use to make the tools we push into s3 [01:52] we're also putting a tarball from the same tag onto the project page [01:52] it sounds like you don't need a recipe, just a package [01:52] which jamespage uses to produce the debs that go into P, Q, R and S [01:52] bigjools: yes, we do need that [01:56] davecheney: we use recipes to produce repeatable builds when versions get bumped. If you're fixing the version with a tag, it doesn't make sense to me. [01:56] unless you;re going to move the tag around ... :) [01:57] bigjools: no, not planning on moving the tag [01:57] I'd just use bzr builddeb or similar then [02:12] shit, https://launchpadlibrarian.net/145546623/buildlog.txt.gz [02:17] davecheney: it's not going to find the juju tag on your packaging branch is it [02:18] oh fuk, right, i understand [02:18] also [02:18] shouldn't all those nests contain versions? [02:18] otherwise it pulls tip [02:19] bigjools: yes they should [02:19] you are correct [02:20] bigjools: that is why I want to move away from lp build recipes [02:20] like I said, recipes are only really useful for repeated builds [02:21] but if you don't use a recipe, you need to separately package all those nested dependencies. [02:21] choices choices :) [02:22] (and wallyworld wonders why this takes ages ... :) [02:23] automation! [03:31] https://code.launchpad.net/~dave-cheney/juju-core/137-revert-temporary-removal-of-azure-provider/+merge/175994 [03:31] ping [04:19] * thumper has one more branch that stabs state.Tools through the heart [04:25] le sigh [04:25] the state is back to retrying > 1 time / second [04:26] i'm tried of trying and failing to fix this bug [04:28] thumper: if you are looking for a shit way to finish your day, i have 3 mp's that need reviewing. or i can beg someone else in EU timezone [04:29] wallyworld: sure [04:29] thanks. i'll still need to beg for the 2nd +1 i suppose :-) [04:30] the simplestreams validation one is especially important [04:33] 66 files changed, 488 insertions(+), 417 deletions(-) [04:33] https://codereview.appspot.com/11561044/ [04:36] us-west-1 is slow, doo daa, doo daa [04:38] * wallyworld looks at thumper's branch before heading off for school pickup [04:38] wallyworld: it is pretty boring [04:39] hopefully easy to review then [04:41] warning: do not read merge proposal while driving, may cause drowsyness [04:43] I'm especially happy with the testing function to check juju-core dependencies [04:53] wallyworld: the message is still valid [04:53] ok [04:53] wallyworld: it used to say that the interface was there to avoid an import loop [04:54] now it is to not bring in the dependency [04:54] fair enough [04:56] axw: how goes the new starter tasks? [04:56] thumper: pretty much all done [04:56] just waiting on hearing back from IS on getting my SSH key added [04:59] anyone know anything about a sprint in August ? [05:01] apparently there is one here [05:01] apparently [05:01] and you all get to learn about the lovely azure [05:02] * davecheney already has his account setup [05:04] * thumper goes to make dinner === thumper is now known as thumper-afk [05:14] 1.11.3 is out! [06:05] when the core asks a provider to open ports, does it differentiate between udp and tcp or does it expect both types to be opened? [06:06] bigjools: the latter [06:06] ta [06:06] the open-port command does not permit you to specify the flavor [06:12] it's required to specify on azure, so ... two calls needed. yay. === tasdomas_afk is now known as tasdomas [06:55] * axw wonders how long before his brain stops automatically doing things the IBM way [06:57] am I better off using the openstack or local provider for familiarising with juju code? local is undergoing quite a bit of change right now? [07:00] axw: yes, local is in a too early stage [07:01] axw: using ec2 is a robust and convenient way to get into it [07:01] axw: good morning btw ;) [07:01] TheMue: thanks. Good morning :) [07:01] first day at Canonical - I'd like to accomplish something more than getting my accounts set up ;) [07:02] axw: and hey, I've still got the IBM way of thinking in my brain, even after now more than one and a half years [07:02] oh, you worked at IBM? [07:02] axw: oh, no, but a long time with ibm technologies. first mainframe, later websphere stuff [07:03] ah right :) [07:03] axw: and in very conservative companies with large and unflexible it [07:03] ;) [07:11] mornin' all [07:14] rogpeppe1: good morning [07:14] axw: yo! welcome! [07:14] thanks :) [07:15] axw: is this your first day? [07:15] rogpeppe1: yes it is [07:16] axw: where do you come from? [07:16] axw: feel free to ask about anything. i imagine you'll probably be busy doing all those initial things, but if you wanna take a look through the code, we're all online [07:16] TheMue: I'm in Perth, Western Australia [07:16] axw: i guess your day is just about ended now, right? [07:17] rogpeppe1: Thanks. Still a few hours left. I'm just getting set up with juju/openstack now [07:17] done all the new starter things [07:17] axw: i've not done the openstack set up yet :-) [07:18] axw: oh, the australian/new zealand group slowly outnumbers the european one [07:18] rogpeppe1: oh, no, I'm just using canonistack [07:18] axw: good reason to have the next meeting in australia :) [07:18] TheMue: :) there do seem to be quite a few people in A/NZ [07:18] axw: yeah, i haven't tried that yet. i probably should... [07:19] rogpeppe1: what do you develop against then? EC2? [07:19] axw: yeah [07:19] TheMue: just not Perth, it's dead boring [07:20] axw: so we'll select Sydney, visiting Dave [07:21] TheMue: Sounds good. I don't mind Sydney. [07:23] axw: never been there, so far only europe, us and india. so it would be a new experience [08:15] who knows about the openstack provider? seems there's a bug where it's expecting authentication to have occurred at bootstrap time [08:17] guys, I need help landing this branch lp:~dimitern/juju-core/073-apiserver-pinger-on-ma-connection - i run the tests like 30 times since friday and it never fails on my machine, but it always fails on the bot - can someone please pull it and run all the tests to see if it can be reproduced? [08:18] axw: can you give more details? [08:19] dimitern: 1. I pulled tip of juju-core; 2. I init'd and configured environments.yaml to target canonistack; 3. juju bootstrap -v [08:19] 2013-07-22 07:58:23 ERROR juju supercommand.go:235 command failed: cannot create bootstrap state file: cannot get endpoint URL without being authenticated [08:19] axw: do you have your canonistack creds in the env? [08:20] dimitern: yes [08:20] dimitern: I can get around this by forcing authentication in goose/client code [08:20] axw: set | grep OS_ [08:20] axw: you should see 5 lines [08:21] dimitern: yes, they're all there [08:21] axw: have you done "go install ." in cmd/juju ? [08:21] after pulling [08:21] dimitern: go get ./... [08:22] dimitern: I don't have another juju installed [08:22] axw: but do you have an existing working dir from before? [08:22] ~/.juju ? [08:22] axw: do go install there, just to be sure it runs the correct binary [08:23] axw: no, the source checkout [08:23] dimitern: I guarantee you it is :) I modified the code to fix the problem [08:23] axw: what was needed? [08:23] goose/client.go: authenticatingClient.MakeServiceURL checks IsAuthenticated [08:23] I changed it to call Authenticate if it's not [08:23] axw: gmm let me see [08:24] I'm just not sure if this is the appropriate place to do it. It's getting called during bootstrap [08:25] axw: can you paste the exact log please? [08:26] mgz: hey, can you help me with a branch i'm having trouble landing [08:26] 2013-07-22 07:58:09 INFO juju provider.go:115 environs/openstack: opening environment "openstack" [08:26] 2013-07-22 07:58:09 INFO juju provider.go:417 environs/openstack: bootstrapping environment "openstack" [08:26] 2013-07-22 07:58:21 INFO juju tools.go:26 environs: reading tools with major version 1 [08:26] 2013-07-22 07:58:23 INFO juju tools.go:30 environs: falling back to public bucket [08:26] 2013-07-22 07:58:23 INFO juju tools.go:53 environs: filtering tools by series: precise [08:26] 2013-07-22 07:58:23 INFO juju tools.go:76 environs: picked newest version: 1.11.0 [08:26] 2013-07-22 07:58:23 ERROR juju supercommand.go:235 command failed: cannot create bootstrap state file: cannot get endpoint URL without being authenticated [08:26] mgz: pull this and run all tests to see if they pass please: lp:~dimitern/juju-core/073-apiserver-pinger-on-ma-connection [08:26] axw: please use paste.ubuntu.com next time :) [08:26] sorry! [08:27] dimitern: SURE [08:27] axw: hmm interesting [08:27] mgz: cheers [08:27] er, caps [08:27] :) [08:27] axw: i'll look into it, might be indeed a bug [08:28] okey dokey, thanks. I'll stick with my patch while I play. [08:28] axw: which revision of goose you're on? [08:29] dimitern: 99 [08:29] dimitern: running tests now [08:29] dimitern: entirely possible I'm out of date... [08:30] hmm nope, seems to be the latest [08:30] axw: it is the latest [08:31] dimitern: would you like me to log a bug? or is this stuff too much in flux for that? [08:33] axw: yes, please do this, so we can triage it and see whether it's a config issue or indeed a goose bug [08:35] axw: against goose i think, not juju-core, as it seems [08:35] ok [08:43] dimitern: either the test run hung after the charmload tests, or something else is very wrong... [08:44] how do I run with -gocheck.v and do all the tests again? >_< [08:45] mgz: you cannot [08:45] mgz: but, if you just go into .. wait a sec [08:46] mgz: state/apiserver and run go test -gocheck.v [08:46] mgz: alas, gocheck doesn't support running tests recursively [09:02] I'm failing to get cmd/juju tests to complete at all... [09:02] with trunk [09:02] I'll give up and just test the ones you care about in your branch [09:02] mgz: ok [09:04] one failure [09:04] http://paste.ubuntu.com/5899884 [09:05] mgz: strange.. go version? [09:05] 1.0.2 from distro [09:06] hmm.. that's probably what the bot is running, but this is wrong, should be 1.0.3 or even 1.1.1 [09:07] 1.02 on the distro has the borked fixes from 1.0.3 so should be much the same [09:07] we did say we were going to switch wholesale to 1.1 [09:07] well, i can't make it break here [09:07] but haven't really pulled the trigger on that yet [09:07] really frustrating.. [09:08] and the logic is sane, should pass [09:08] the bot has 1.0.3 [09:08] at least that's what I get when I ssh in and run go version [09:09] if it helps, you can run that test yourself on my setup [09:09] ideas how to debug this on the bot without stopping it? [09:09] if the bot failing on the same test as me? [09:09] it is [09:10] hmm.. i'll try to find another way to test the same thing [09:10] if so, ssh 10.55.60.158 and play around [09:10] ok [09:10] thanks btw [09:18] mgz: if I can bug you a bit more :) [09:18] sure :) [09:18] mgz: added some logging to the branch, so if you pull it now [09:19] mgz: and then run go test -gocheck.vv -gocheck.f TestMachineLoginStartsPinger [09:19] mgz: pasting the output, I should get better idea [09:19] ssh in and see yourself :) [09:20] mgz: I wouldn't want to screw up the bot [09:20] it's not the bot [09:20] mgz: aah, ok [09:20] it's my test server [09:20] thanks [09:20] cd go/src/launchpad.net/juju-core [09:20] then run the last command [09:21] mgz: when I do bzr pull there it says perm denied [09:21] I already pulled [09:21] mgz: ah, ok [09:21] (you need forwarding for that to work) [09:22] mgz: ha! it passes now [09:22] hm, failed once for me [09:22] run it a few more times [09:22] mgz: weird.. so it's a timing issue then - adding two log statements seems to have fixed it [09:23] http://paste.ubuntu.com/5899917 [09:24] mgz: I can't see this - I run it like 5 times, all pass [09:24] logging probably made the race harder to hit [09:24] http://paste.ubuntu.com/5899920/ [09:24] it passed the last few times for me.... just failed again [09:24] mgz: that's indeed disturbing [09:25] but what i can say is that the pinger gets killed in both cases [09:25] just some timeout is needed perhaps after that [09:31] mgz: sorry, can you pull again please? [09:37] i'm approving it with the last fix, fingers crossed it might pass [09:39] is there a primer anywhere on the procedure for changesets? how to get it reviewed, etc. [09:41] axw: basically, you create a merge proposal with lbox propose and it gets reviewed on rietveld, you need 2 LGTMs, then you should set the commit message on LP and mark it as approved, the bot will land it [09:42] dimitern: thanks. [09:42] axw: note: you'll need go 1.1.1 to compile launchpad.net/lbox/... [09:43] ymmv [09:46] dimitern: done, sorry, was off in the clouds [09:48] mgz: thanks, run it 10 times, passes, finally! [09:48] tyvm [09:58] rogpeppe1: ping [09:59] dimitern: poing [09:59] rogpeppe1: it seems there's a problem with provisioner tests after the short/longwait stuff has landed [09:59] dimitern: ah [10:00] dimitern: is that why the bot is failing? [10:00] rogpeppe1: http://paste.ubuntu.com/5900029/ [10:00] rogpeppe1: yeah, I've seen this on several other branches trying to land [10:01] rogpeppe1: I might be wrong, but it seems like the most probable cause, can you look into it please? [10:02] dimitern: ah, i think i see where the problem might lie [10:03] rogpeppe1: it seems in one place it was 200ms and was changed to shortwait [10:03] dimitern: http://paste.ubuntu.com/5900040/ [10:03] dimitern: it assumes that a short wait is enough to check for no operations *and* to wait for the operation to be performed [10:04] rogpeppe1: yeah [10:04] dimitern: it should probably loop polling Status [10:04] rogpeppe1: it wasn't shortwait before [10:04] rogpeppe1: lxc-broker_test.go in ensureNoChanges [10:04] rogpeppe1: it was 200ms [10:05] dimitern: agreed. but ensureNoChanges should not also be ensureEnoughTimeForSomethingToHappen [10:05] good night all [10:05] axw: g'night! [10:05] dimitern: it was only lucky that we weren't using a shorter timeout for ensureNoChanges [10:05] axw: 'night [10:06] rogpeppe1: seems likely yes [10:06] dimitern: i think this is useful stuff to find out - it will make our tests less flaky in the end [10:07] dimitern: i'd like to try running the tests with ShortWait=1 * time.Microsecond [10:07] dimitern: and make sure nothing breaks with that [10:07] rogpeppe1: why? that seems extreme [10:08] dimitern: it's important that we don't *rely* on anything happening within the ShortWait time scale [10:08]