| wwitzel3 | wallyworld_: will re-running go get on juju-core ensure the proper dependancies get updated? Or is there an easy way to go get -u all of the entries in dependancies.tsv? | 00:12 |
|---|---|---|
| wallyworld_ | go get -u on launchpad.net/juju-core should do deps, but | 00:13 |
| wallyworld_ | go has no proper dependency management like python etc | 00:14 |
| wallyworld_ | i think it just pulls trunk | 00:14 |
| wwitzel3 | right, thank you | 00:14 |
| wallyworld_ | the dependencies.tsv file is used with tooling by the CI | 00:14 |
| wallyworld_ | not by go itself | 00:14 |
| wwitzel3 | ahh ok, makes sense, was wondering what that was for | 00:14 |
| wallyworld_ | i lot of us are very disappointed with go's dep management | 00:15 |
| wallyworld_ | the designers think it's ok to build against trunk of all the deps | 00:15 |
| wallyworld_ | which is so crackful i don't know where to start | 00:15 |
| bodie_ | heh | 00:15 |
| bodie_ | crackful | 00:15 |
| bodie_ | so if I want to update ALL THE THINGS can I just go get -u launchpad.net/... ? | 00:16 |
| bodie_ | or will that go get everything on launchpad.net ? | 00:16 |
| bodie_ | I tried asking in #go-nuts, but they were snarky because they didn't know :P | 00:16 |
| wallyworld_ | not sure actually | 00:16 |
| wallyworld_ | not sure if it just looks on disk | 00:16 |
| bodie_ | dyou have a way to update a local tree? | 00:16 |
| wallyworld_ | i normally use bzr to get the required rev | 00:17 |
| wallyworld_ | by hand :-( | 00:17 |
| * bodie_ offers wallyworld_ a consolation beer | 00:17 | |
| wallyworld_ | cause i don't trust just building against trunk of all the deps | 00:17 |
| bodie_ | hm | 00:17 |
| * wallyworld_ slurps the virtual beer | 00:17 | |
| wallyworld_ | from what i recall, the go guys said that dependency management is hard so let's just ignore it :-( | 00:18 |
| bodie_ | looks like go get -u <thing>/... works | 00:18 |
| wallyworld_ | great | 00:19 |
| wwitzel3 | wallyworld_: yeah, I've seen projects using two accounts on github, -dev and -stable, which I guess works for ensuring you are working off some random rev of master | 00:20 |
| wwitzel3 | are not | 00:20 |
| wallyworld_ | yeah | 00:21 |
| _thumper_ | waigani: next you could do the tests for optional autostart for lxc | 01:35 |
| _thumper_ | waigani: although we shouldn't land this until we have "suspend" and "resume" | 01:35 |
| _thumper_ | otherwise we have no way to restart a non-autostarting environment | 01:36 |
| waigani | _thumper_: okay, so where do I get started with the "suspend" and "resume" stuff | 01:41 |
| waigani | wallyworld_: what was the bug you mentioned I could look at? | 01:42 |
| wallyworld_ | it's on the 1.17.5 milestone page, let me check | 01:42 |
| waigani | _thumper_: i.e. is there any relevant code or am I introducing this as a new feature, in which case I'll go play with the cli lxc suspend and resume | 01:43 |
| wallyworld_ | waigani: https://launchpad.net/bugs/1291165 | 01:44 |
| _mup_ | Bug #1291165: juju bootstrap local cannot bootstrap <ppc64el> <juju-core:Incomplete> <https://launchpad.net/bugs/1291165> | 01:45 |
| waigani | wallyworld_: cheers | 01:45 |
| wallyworld_ | ah someone has marked it incomplete | 01:45 |
| wallyworld_ | but still | 01:45 |
| wallyworld_ | if there's an empty jenv file, we should be able to nuke it | 01:45 |
| thumper | davecheney: hey | 02:42 |
| thumper | davecheney: how's things going? | 02:42 |
| thumper | wallyworld_: https://codereview.appspot.com/74370044/ | 02:44 |
| wallyworld_ | looking | 02:44 |
| thumper | axw: that azure branch is a monster | 02:46 |
| thumper | axw: no changes in gwacl? | 02:46 |
| thumper | ah, can see it | 02:46 |
| thumper | yes there is | 02:46 |
| thumper | axw: but I guess all the gwacl stuff needed is reviewed and landed already | 02:47 |
| thumper | wallyworld_: I did add some tests around the autostart for the template and the clone | 02:48 |
| wallyworld_ | ok, i missed those then :-) | 02:49 |
| thumper | https://codereview.appspot.com/74370044/diff2/1:20001/container/lxc/lxc_test.go | 02:49 |
| wallyworld_ | great | 02:49 |
| davecheney | thumper: o/ | 02:49 |
| davecheney | still fighting with proxy prolems | 02:50 |
| davecheney | just adding some more debug to juju | 02:50 |
| thumper | davecheney: what sort of problems? | 02:50 |
| davecheney | not obeying no_proxy | 02:50 |
| davecheney | i guess | 02:50 |
| davecheney | you have to be very explicit in the no_proxy list | 02:50 |
| axw | thumper: sorry, was in the zone | 02:51 |
| thumper | axw: np | 02:51 |
| axw | yes, monstrous in several ways | 02:51 |
| thumper | davecheney: but no_proxy is at least being propogated? | 02:51 |
| thumper | axw: I was going to do the initial review for your branch | 02:52 |
| thumper | and trying not to get put off by the shear size :-) | 02:52 |
| axw | thumper: sorry :( | 02:52 |
| thumper | axw: :-) | 02:53 |
| axw | I've tried to make it as minimal as I can | 02:53 |
| thumper | hey, at least it is just four files :) | 02:53 |
| axw | hehe | 02:53 |
| thumper | reasonably isolated | 02:53 |
| axw | I just rewrote those four files :) | 02:53 |
| thumper | axw: so this branch doesn't put multiple machines into a single cloud service yet? | 02:54 |
| axw | thumper: no. well, state servers will - but we don't spawn multiple of them yet | 02:55 |
| thumper | hah | 02:55 |
| thumper | ok | 02:55 |
| thumper | just didn't want to get confused more than usual reading the code | 02:55 |
| jcastro | hey thumper | 02:56 |
| axw | thumper: let me know if you need any explanations on the azure concepts | 02:56 |
| thumper | o/ jcastro | 02:56 |
| jcastro | theorize with me. | 02:56 |
| thumper | axw: sure | 02:56 |
| thumper | jcastro: oh... kay... | 02:56 |
| jcastro | so you know how you can add servers via the manual provider | 02:56 |
| jcastro | what's to stop me from adding some servers from aws, some from azure, some from hp | 02:57 |
| jcastro | and doing a poor man's cross environment relations? | 02:57 |
| thumper | jcastro: they won't be able to talk to each other | 02:57 |
| thumper | jcastro: the units use the internal private address | 02:57 |
| axw | jcastro: they won't have the same internal addresses | 02:57 |
| thumper | which is cloud (or region) private | 02:57 |
| axw | what thumper said | 02:57 |
| jcastro | so even if I was to try and trick them with say openvpn or whatever | 02:58 |
| jcastro | bah! so close! | 02:58 |
| thumper | yes, close | 02:58 |
| axw | if you set up all the routing yourself you could do it | 02:58 |
| thumper | I forsee a time when we use our own SDN for juju, so this would work | 02:58 |
| thumper | but this isn't in the near future | 02:58 |
| thumper | perhaps 6-12 months if we're lucky | 02:58 |
| * jcastro nods | 02:59 | |
| waigani | thumper: lxc-freeze/lxc-unfreeze == suspend/resume? | 03:00 |
| davecheney | thumper: i think so | 03:01 |
| davecheney | i need to find out which host is getting knocked back by the proxy | 03:01 |
| waigani | davecheney: cheers | 03:01 |
| thumper | waigani: no... I don't think so | 03:01 |
| thumper | waigani: because when a machine stops or is rebooted | 03:01 |
| thumper | waigani: the machine is in a stopped state, not a frozen state | 03:01 |
| thumper | so better to be consistent | 03:01 |
| thumper | perhaps after the initial approach | 03:01 |
| thumper | we could use freeze/unfreeze in addition to start/stop | 03:02 |
| thumper | if necessary | 03:02 |
| thumper | but start/stop are bare minimum necessary | 03:02 |
| waigani | thumper: oh right, I assumed we already had that and you wanted suspend/resume in addition | 03:03 |
| thumper | waigani: no... | 03:03 |
| thumper | it's complicated | 03:03 |
| axw | thumper: I think it's best to leave this Azure stuff till after 1.18.0 in case it destabilises - what do you think? | 03:11 |
| thumper | hmm... | 03:12 |
| thumper | well, it would only destabalize azure | 03:12 |
| thumper | and they have kinda asked for it :-) | 03:12 |
| thumper | I'll punt the question to mramm | 03:12 |
| thumper | and extras | 03:12 |
| axw | ok | 03:12 |
| thumper | I'll put it on the minutes for tonight's meeting | 03:12 |
| thumper | and we'll make a decision | 03:12 |
| axw | okey dokey | 03:12 |
| waigani | wallyworld_, thumper: is there a way to look at trunk without switching to it? | 03:31 |
| wallyworld_ | you can browse from launchpad | 03:31 |
| waigani | from the filesystem? | 03:31 |
| wallyworld_ | from the browser | 03:32 |
| waigani | it would be handy to have trunk in a sublime window | 03:32 |
| wallyworld_ | or you can branch it locally somewhere | 03:32 |
| wallyworld_ | in that case, just branch locally | 03:32 |
| waigani | ah okay | 03:32 |
| davecheney | thumper: resp, err := utils.GetNonValidatingHTTPClient().Do(req) | 03:40 |
| davecheney | if err != nil { | 03:40 |
| davecheney | return nil, fmt.Errorf("cannot upload charm: %v", err) | 03:40 |
| davecheney | ^ this http client doesn't observe the proxy | 03:40 |
| davecheney | or doesn't obey the proxy exclusion, or something | 03:42 |
| davecheney | no | 03:43 |
| davecheney | wait | 03:43 |
| davecheney | its somewhere else | 03:43 |
| davecheney | 2014-03-13 03:43:40 ERROR juju.cmd supercommand.go:296 failed to add remote charm "cs:precise/ubuntu-4": cannot upload charm to provider storage: 403 403 Forbidden | 03:44 |
| thumper | hmm.. | 03:51 |
| * thumper is still in axw's first file | 03:52 | |
| davecheney | thumper: still chasing | 03:55 |
| davecheney | it's in storage.Puit | 03:55 |
| davecheney | and this must be posting to the little web server the local provider stands up | 03:55 |
| davecheney | i just need to find out which localhost addr it is sitting on | 03:55 |
| axw | davecheney: should be in lxcbr0 | 03:58 |
| thumper | 10.0.3.1 is the host | 04:00 |
| thumper | davecheney: can you do 10.0.3.0/24 ? | 04:01 |
| thumper | waigani: what'cha up to? | 04:04 |
| thumper | waigani: because I have a few refactorings I'd like to see landed ASAP | 04:04 |
| thumper | :) | 04:04 |
| * thumper sighs | 04:05 | |
| thumper | two down, two to go | 04:05 |
| davecheney | thumper: i don't think so | 04:05 |
| davecheney | i migth be able to do 10.0.3 | 04:05 |
| davecheney | i think it's just a substring map | 04:05 |
| davecheney | thumper: i already added 10.0.3.1 to the list | 04:05 |
| waigani | thumper: girl just got off the ice. I have to head home and do dinner/homework daddy thing. After that? | 04:05 |
| waigani | or email me and I'll pick it up this evening | 04:06 |
| thumper | davecheney: http://unix.stackexchange.com/questions/23452/set-a-network-range-in-the-no-proxy-environment-variable | 04:07 |
| davecheney | thumper: intersting | 04:08 |
| axw | thumper: was it as good for you as it was for me? | 04:41 |
| thumper | axw: probably a lot less of a pain for me | 04:41 |
| axw | reviews can be quite tiring | 04:42 |
| wallyworld_ | thumper: me is sad | 06:06 |
| wallyworld_ | ERROR juju.cmd supercommand.go:293 empty http-proxy in environment configuration | 06:06 |
| wallyworld_ | save me looking, any idea? | 06:07 |
| wallyworld_ | there is no http-proxy in my env config | 06:07 |
| wallyworld_ | never has been | 06:07 |
| wallyworld_ | ah fark, wrong environment | 06:08 |
| wallyworld_ | that was with local | 06:08 |
| dimitern | hey thumper | 06:45 |
| waigani_ | thumper: I accidentally cancelled during a commit. branch is locked. bzr break-lock: The lock for [branch] is in use and cannot be broken. | 07:25 |
| waigani_ | thumper: bzr info: Could not acquire lock "...go/src/launchpad.net/juju-core/.bzr/checkout/dirstate": [Errno 11] Resource temporarily unavailable | 07:28 |
| mattyw | waigani_, can you try doing this? bzr break-lock bzr+ssh://example.com/bzr/foo with the bzr+ssh pointing to the remote branch | 07:29 |
| mattyw | ^^ah right during a commit - not a push - I suspect my "advice" is worthless here | 07:30 |
| waigani_ | mattyw: yeah during commit $#@$ | 07:33 |
| waigani_ | axw? wallyworld_? ^ | 07:34 |
| axw | waigani_: I did that once, and thumper had to walk me through fixing it... I can't remember the details sorry | 07:36 |
| waigani_ | hmmmm | 07:37 |
| waigani_ | thumper: never mind, I fixed it | 07:52 |
| waigani_ | wallyworld_: can I bzr switch -b [branch] in a new terminal while lbox proposing in another? | 07:56 |
| waigani_ | axw: ^ ? | 07:56 |
| axw | waigani_: no | 07:57 |
| waigani_ | okay, np | 07:57 |
| jam | dimitern: good morning | 09:21 |
| dimitern | jam, morning! | 09:21 |
| jam | dimitern: I'd like to have vladk do some work with you to get up to speed on juju-core | 09:21 |
| jam | dimitern: do you think you can spend some time pairing with him today ? | 09:22 |
| dimitern | jam, sure, after the weekly meeting perhaps? I need to get this fix done first. | 09:22 |
| jam | dimitern: that should be fine, I think he's still got infrastructure stuff to do today | 09:23 |
| jam | vladk: did you need something ? It sounded like you were just saying something as I closed the window | 09:38 |
| thumper | dimitern: o/ | 09:43 |
| dimitern | thumper, hey - seen my mail? | 09:43 |
| thumper | yes, will get on it | 09:44 |
| jam | fwereade: standup ? | 10:02 |
| jam | mramm: welcome | 10:02 |
| dimitern | mramm, fwereade, rogpeppe, mgz_, meeting? | 10:02 |
| rogpeppe | dimitern: ah yes | 10:02 |
| dimitern | voidspace, ^^ | 10:03 |
| wallyworld_ | fwereade: i really want to get this in for 1.18 because API https://codereview.appspot.com/75330043 | 10:14 |
| dimitern | wallyworld_, are you working on bug 1291207? | 10:20 |
| _mup_ | Bug #1291207: juju-run symlink is broken after upgrade-juju <run> <upgrade-juju> <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1291207> | 10:20 |
| wallyworld_ | dimitern: no | 10:20 |
| voidspace | oh, is there a meeting now | 10:20 |
| dimitern | wallyworld_, ok | 10:20 |
| wallyworld_ | dimitern: axw was going to i think | 10:20 |
| wallyworld_ | voidspace: come and join us :-) | 10:21 |
| voidspace | wallyworld_: coming. | 10:21 |
| voidspace | I did not know we had meetings at a different time on Thursdays! | 10:22 |
| wallyworld_ | Thursdays are special | 10:22 |
| dimitern | voidspace, it's just this one | 10:22 |
| axw | I wasn't planning to work on that bug... | 10:22 |
| axw | I just reported it :) | 10:22 |
| voidspace | dimitern: you mean just today, or just Thursday? | 10:22 |
| dimitern | axw, wallyworld_, ok so if I can get to it I'll fix it today | 10:23 |
| jam | voidspace: thursday is everyone, so we go a bit earlier to make it work for NZ | 10:23 |
| axw | (currently deep into Azure) | 10:23 |
| axw | thanks dimitern | 10:23 |
| wallyworld_ | dimitern: \o/ | 10:23 |
| dimitern | voidspace, every thursday | 10:23 |
| voidspace | dimitern: thanks | 10:23 |
| voidspace | so my code review suggests I should add global state and reduce test coverage! | 10:24 |
| voidspace | amongst some more sensible comments ;-) | 10:24 |
| * dimitern raises 2 crossed fingers in disgust... | 10:27 | |
| dimitern | hey sinzui, what's your plan for the 1.17.5 release? immediately after fixing the critical issues? | 10:29 |
| voidspace | ah, the suggestion to reduce test coverage *does* suggest removing the code that was being tested too, so not entirely crazy :-) | 10:31 |
| dimitern | axw, re bug 1291292 - the manual bootstrap writes provider-state-url file with a hardcoded file:///<storage-path>/provider-state | 10:42 |
| _mup_ | Bug #1291292: use a utils/http client for all HTTP(S) calls across the codebase <manual-provider> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1291292> | 10:42 |
| dimitern | axw, and it does that because I guess p-s-url being an url, it's read with bootstrap.LoadStateFromURL | 10:43 |
| axw | dimitern: it should be http:// though. I will try to remember to take a look later | 10:45 |
| axw | machine-0 starts an httpstorage listener | 10:45 |
| dimitern | axw, it starts an sshstorage in either bootstrap or provisioning mode (can't remember) | 10:46 |
| axw | only command line should be using sshstorage - could be an issue around there | 10:46 |
| dimitern | axw, seemed so to me as well | 10:47 |
| dimitern | fwereade, i've assigned to myself all bugs i'm working on today - basically i need to get upgrades from 1.16 going smoothly | 11:01 |
| fwereade | dimitern, ok, excellent; you and mgz will need to do vlans as a matter of some urgency though | 11:01 |
| wallyworld_ | jam: fwereade: i've tested this live upgrading from all of 1.16, 1.17, 1.18. I would love to get it in to 1.18 so we can delete lots of code post 1.18 https://codereview.appspot.com/75330043 | 11:06 |
| voidspace | mgz_: I'm just butchering our mp in response to the review from rogpeppe | 11:06 |
| wwitzel3 | rogpeppe: did you see my comment on the br0 bug? | 11:06 |
| jam | dimitern: rogpeppe: vladk: Dimiter has mentioned that he's a bit swamped with some critical bug fixes. Roger, is it possible for you to spend some time with vladk looking over your shoulder about the work your on? | 11:06 |
| rogpeppe | jam: sure | 11:07 |
| rogpeppe | wwitzel3: no | 11:07 |
| voidspace | mgz_: although rogpeppe and natefinch suggest adding global state to the tests | 11:07 |
| rogpeppe | voidspace: ?? | 11:07 |
| rogpeppe | voidspace: what global state? | 11:07 |
| voidspace | rogpeppe: using a global variable instead of a hard coded exception | 11:07 |
| voidspace | rogpeppe: I solved it a different way instead :-) | 11:07 |
| rogpeppe | voidspace: that's not global state actually | 11:07 |
| voidspace | rogpeppe: which you *also* hinted at in a different part of the review | 11:07 |
| rogpeppe | voidspace: but i also suggested another way | 11:07 |
| rogpeppe | voidspace: yeah | 11:08 |
| wwitzel3 | rogpeppe: short version, I did the same set of tests we did yesterday using trunk and it all worked. | 11:08 |
| rogpeppe | wwitzel3: bugger | 11:08 |
| rogpeppe | oh for a real maas | 11:08 |
| voidspace | rogpeppe: using aggregator.instanceInfo instead of the reqc channel directly improves the tests a lot | 11:09 |
| voidspace | rogpeppe: so thanks for that | 11:09 |
| rogpeppe | voidspace: cool | 11:09 |
| voidspace | rogpeppe: just going through making all those changes | 11:09 |
| voidspace | rogpeppe: and I have a question about the removal of the loop exit - but it's in my reply to the review so you can read it and answer when I'm done | 11:09 |
| rogpeppe | voidspace: the only test coverage i suggested removing was inappropriately messing with private state - if we're going to do that, then there are *many* more tests we can do :-) | 11:10 |
| thumper | night all | 11:10 |
| rogpeppe | thumper: g'night | 11:10 |
| voidspace | rogpeppe: we have code to handle the channel dying | 11:10 |
| rogpeppe | voidspace: i suggested removing that | 11:10 |
| voidspace | rogpeppe: right | 11:10 |
| rogpeppe | voidspace: because we never actually close the channel | 11:10 |
| voidspace | rogpeppe: however, my follow up question is | 11:11 |
| voidspace | rogpeppe: inside newAggregator we have the inner func which wraps the loop call in tomb.Kill with a defered tomb.Done | 11:11 |
| voidspace | rogpeppe: which we didn't see an easy way to test | 11:11 |
| voidspace | rogpeppe: as loop exit is now not *possble* shouldn't that code be removed too? | 11:11 |
| rogpeppe | voidspace: the loop does exit when the tomb is killed | 11:12 |
| voidspace | right, there's still the tomb exit | 11:12 |
| voidspace | I forgot about that return | 11:12 |
| voidspace | ok | 11:12 |
| rogpeppe | voidspace: when that happens, tomb.Done will be called | 11:12 |
| rogpeppe | voidspace: and if that's not called, then Wait won't return | 11:12 |
| rogpeppe | voidspace: so we are testing it AFAICS | 11:12 |
| voidspace | rogpeppe: I thought we were removing the only return from the loop, but we aren't | 11:12 |
| voidspace | so fine, that's my answer - thanks | 11:13 |
| rogpeppe | voidspace: cool | 11:13 |
| gnuoy | Hi, I just got stung by Bug#1243827 , is there a work around for it or a fix in the pipeline ? | 11:13 |
| _mup_ | Bug #1243827: juju is stripping underscore from options <canonical-webops> <config> <juju-core:Triaged by adeuring> <juju-deployer:Invalid by hazmat> <https://launchpad.net/bugs/1243827> | 11:13 |
| voidspace | I'm very happy to remove tests if we also remove the code being tested | 11:13 |
| rogpeppe | voidspace: it occurred to me that there are actually no tests that the requests are issued at the expected rate | 11:13 |
| adeuring | gnuoy: put the data into quotation marks | 11:14 |
| voidspace | rogpeppe: that gatherTime is honoured? | 11:14 |
| rogpeppe | voidspace: yeah | 11:14 |
| voidspace | rogpeppe: well, that's a ratelimiter detail - so that should be tested inside ratelimiter | 11:14 |
| gnuoy | adeuring, I'll give that a try, thanks | 11:14 |
| voidspace | rogpeppe: we test that they're batched by the ratelimiter | 11:14 |
| voidspace | rogpeppe: we don't test that our gatherTime is *passed* to the ratelimiter, but if they're batched (which we do test) I think it's fair to just assume that | 11:14 |
| rogpeppe | voidspace: kinda. we test some batching, but we don't really check that we're using the ratelimiter appropriately. | 11:15 |
| adeuring | gnuoy: ...or use double underscores. But that will require a change in the config once the bug is fixed. (and I am quite close to having a fix) | 11:15 |
| voidspace | rogpeppe: so I could test that the time taken for the batched request to return is greater than gatherTime | 11:15 |
| rogpeppe | voidspace: i believe it works, but i woke up this morning thinking that it didn't, and had to write a little piece of code to convince me itdid | 11:15 |
| voidspace | rogpeppe: a simple assertion that timeTakenToBatch > gatherTIme then? | 11:15 |
| voidspace | rogpeppe: I don't want to test the semantics of the ratelimiter inside the aggregator tests - the ratelimiter should be tested inside ratelimiter | 11:16 |
| rogpeppe | voidspace: i'd actually prefer something that calls instanceInfo several times (say 100 times at 1ms intervals, with gatherTime say to 10ms) and check that the total number of requests issued is no more than 10 | 11:16 |
| voidspace | rogpeppe: that does sound like testing the ratelimiter works | 11:17 |
| rogpeppe | voidspace: i do hear you there, but it's actually just testing one incarnation of the ratelimiter, and that we are using it appropriately. | 11:18 |
| rogpeppe | voidspace: it would be quite easy to do it wrongly | 11:18 |
| rogpeppe | voidspace: that said, i believe the code works, so i'm happy to go forward with the existing tests if you're happy with them | 11:18 |
| voidspace | rogpeppe: I could add a (threadsafe *sigh*) counter to testInstanceGetter | 11:18 |
| voidspace | rogpeppe: so it wouldn't be hard to write | 11:18 |
| voidspace | rogpeppe: just fire off a bunch of requests, ensure none of them error and that testInstanceGetter.counter <= 10 | 11:19 |
| rogpeppe | voidspace: yeah | 11:19 |
| rogpeppe | voidspace: sync/atomic can be useful for thread-safe counters, if you haven't already added a mutex | 11:20 |
| voidspace | rogpeppe: the existing batch test also ensures that the right response goes back to the right request - so it still has value "as is" | 11:20 |
| rogpeppe | voidspace: definitely | 11:20 |
| voidspace | rogpeppe: I don't think we need a mutex in the place you suggested one | 11:20 |
| rogpeppe | voidspace: ok | 11:20 |
| voidspace | rogpeppe: as we're doing a blocking read so we *can* actually know there is no concurrency issue in that specific place | 11:20 |
| voidspace | rogpeppe: the batched requests that set instanceGetter.ids can only happen after the first request completes | 11:20 |
| rogpeppe | voidspace: that does assume a particular implementation, but i'm happy with that | 11:21 |
| rogpeppe | voidspace: we don't do black-box testing | 11:21 |
| voidspace | rogpeppe: well, it assumes that we can only get a reply after the request has been sent | 11:21 |
| voidspace | rogpeppe: so we're assuming a particular implementation of the *universe* | 11:22 |
| voidspace | ;-) | 11:22 |
| voidspace | as we wait for the reply before making the next request | 11:22 |
| voidspace | I don't *think* that makes assumptions about the implementation | 11:22 |
| rogpeppe | voidspace: it assumes that the loop doesn't call Instances again after sending the reply | 11:22 |
| voidspace | rogpeppe: we know there are no other requests coming in | 11:23 |
| rogpeppe | voidspace: but that would indeed be a hard mistake to make | 11:23 |
| rogpeppe | voidspace: i was not seriously suggesting adding a mutex, in all honesty | 11:23 |
| voidspace | ok | 11:23 |
| rogpeppe | voidspace: just pointing out the potential issue - it's a common pattern to see, and raises warning signs in my head | 11:24 |
| voidspace | I've worked with threads before | 11:24 |
| voidspace | so I'm no stranger to concurrency pain | 11:24 |
| rogpeppe | voidspace: :-) | 11:24 |
| rogpeppe | voidspace: given the above, you probably won't need a thread-safe counter either | 11:25 |
| rogpeppe | voidspace: as you know that instances is always called from a single thread | 11:25 |
| voidspace | no, we need to batch 100 calls concurrently as we can't use instanceInfo synchronously if we want batching | 11:25 |
| voidspace | and a plain increment won't be thread safe | 11:25 |
| voidspace | so I think we will | 11:26 |
| voidspace | although you maybe right - let me think about it | 11:26 |
| rogpeppe | voidspace: we can make 100 calls concurrently, but Instances will only be called from a single thread | 11:26 |
| voidspace | ah yes | 11:26 |
| voidspace | we make the requests from 100 different goroutines - but the instance is accessed just from the loop goroutine | 11:27 |
| rogpeppe | voidspace: yeah | 11:27 |
| voidspace | cool | 11:27 |
| rogpeppe | voidspace: that said, we really are assuming an implementation here - the previous implementation of instanceInfo *would* have called Instances concurrently | 11:27 |
| rogpeppe | voidspace: so probably best to use atomic.AddInt32 or whatever , just to be on the safe side | 11:28 |
| rogpeppe | voidspace: then you can easily verify that the tests fail against the old version of the code if you wish | 11:28 |
| voidspace | fair enough | 11:28 |
| voidspace | a big part of my work with paymentservice was implementing correct locking to solve our concurrent database access problems - that was *worse* though because the concurrent access was from different processes, and actions that acquired the lock could trigger other actions in other processes that needed the lock too | 11:29 |
| voidspace | so we had to add locking without deadlocking | 11:29 |
| voidspace | we ended up with a state machine to handle the actions (state transitions) and also do the locking in basically *one place* | 11:29 |
| voidspace | but before then we had to add careful locking everywhere we found a race condition | 11:29 |
| voidspace | coffee | 11:30 |
| rogpeppe | voidspace: yeah, mutexes work ok in simple situations, but for more complex situations, a single thread makes things easier | 11:30 |
| voidspace | and William and I have some fun horror stories about threading from Resolver Systems - we changed the main calculation engine to work in a background thread (to not block the UI and allow multiple concurrent calclulations) | 11:31 |
| rogpeppe | voidspace: database locking is awkward because you don't really want a monitor process either | 11:31 |
| voidspace | but syncing the results back to the UI had to happen on the UI thread | 11:31 |
| rogpeppe | voidspace: ha ha | 11:31 |
| voidspace | we spent *days* finding and fixing race conditions | 11:31 |
| voidspace | including multiple iterations of "I can *prove* that what just happened can't happen" | 11:31 |
| rogpeppe | voidspace: a nice idiom in Go can be to send a function on a channel, which then gets executed by the monitor thread | 11:32 |
| voidspace | rogpeppe: yes, being able to send functions on channels is very nice | 11:32 |
| voidspace | similar to InvokeOnThread (or whatever it's called) in C# - which kinda-sorta has function pointers in the form of delegates | 11:33 |
| voidspace | actually, it's functional programming support improved massively after I stopped using it | 11:33 |
| rogpeppe | voidspace: yes, except that InvokeOnThread sounds like you can tell some code to execute on any arbitrary thread | 11:34 |
| voidspace | only if there's an event loop running | 11:34 |
| voidspace | so for the main GUI event loop you can pass a delegate and say "execute this delegate on the GUI thread and return the results to me" | 11:34 |
| rogpeppe | voidspace: right | 11:34 |
| voidspace | which yes, isn't the same as sending a function across a channel - just reminded me of it I guess | 11:35 |
| rogpeppe | voidspace: if you have generalised "event loops" it makes sense | 11:35 |
| voidspace | yep, you could run multiple event loops in different threads | 11:35 |
| voidspace | anyway, coffee time for me | 11:36 |
| rogpeppe | voidspace: enjoy | 11:36 |
| voidspace | :-) | 11:36 |
| rogpeppe | vladk: hi | 11:39 |
| rogpeppe | vladk: when you feel that you've caught up with what you want to do, perhaps we could hang out together, as john suggested | 11:41 |
| vladk | rogpeppe: may we hangout in an hour? I'm a little busy right now | 11:42 |
| rogpeppe | vladk: sounds good | 11:43 |
| rogpeppe | vladk: ping me when you're ready | 11:43 |
| vladk | rogpeppe: ok | 11:43 |
| wwitzel3 | rogpeppe: https://codereview.appspot.com/72270044/ | 11:47 |
| wwitzel3 | rogpeppe: I made those changes we discussed yesterday | 11:47 |
| rogpeppe | wwitzel3: looking | 11:47 |
| wwitzel3 | rogpeppe: also I was able to replicate the error from your ticket (1271144) | 12:04 |
| wwitzel3 | rogpeppe: but am not able to replicate it on your branch :) | 12:04 |
| wwitzel3 | rogpeppe: it is intermitten on trunk, but I can make it happen | 12:04 |
| adeuring | gnuoy: doies the string where the "_" is removed start with a "-" of "+" (just to confirm that I'm on the right track) | 12:04 |
| rogpeppe | wwitzel3: great! | 12:04 |
| rogpeppe | wwitzel3: that's a relief | 12:04 |
| wwitzel3 | http://paste.ubuntu.com/7084302/ | 12:05 |
| gnuoy | adeuring, yes, it starts with a "-" | 12:05 |
| adeuring | gnuoy: great, thanks! | 12:05 |
| gnuoy | np | 12:06 |
| wwitzel3 | rogpeppe: haha, I just looked at the diff for that fix | 12:08 |
| rogpeppe | wwitzel3: loadsa code :-) | 12:11 |
| wwitzel3 | rogpeppe: well for what it's worth, after the testing, LGTM | 12:14 |
| rogpeppe | wwitzel3: you have a review | 12:17 |
| bodie_ | o/ | 12:18 |
| voidspace | rogpeppe: so no issues with doing test checks inside a goroutine? | 12:25 |
| voidspace | rogpeppe: I assume you do check rather than assert because you shouldn't assert inside a goroutine | 12:25 |
| rogpeppe | voidspace: Check is considered ok; Assert is not | 12:25 |
| rogpeppe | voidspace: yeah | 12:25 |
| voidspace | rogpeppe: but a check can happily add a failure whereas an Assert can't just stop | 12:25 |
| voidspace | right | 12:25 |
| rogpeppe | voidspace: in fact it doesn't matter, but this is the party line | 12:26 |
| voidspace | ah, ok | 12:26 |
| voidspace | it does change the semantics of the test slightly (using Check rather than Assert) | 12:26 |
| voidspace | in that we won't fail early | 12:26 |
| voidspace | but no harm | 12:26 |
| rogpeppe | voidspace: yeah, but i don't think it matters | 12:26 |
| voidspace | rogpeppe: I'm intruiged as to how it doesn't matter | 12:26 |
| sinzui | dimitern, yes, as soon as the blocking bugs are fixed. I may release without the fix for cloud-init in maas, release that in 1.18.0 | 12:27 |
| voidspace | rogpeppe: if you do an assert does the test runner kill all running goroutines and terminate the test method? | 12:27 |
| voidspace | in fact I wonder how the test runner works at all without exceptiosn - does it use a panic? | 12:27 |
| rogpeppe | voidspace: check out the implementation of Assert | 12:27 |
| rogpeppe | voidspace: it calls runtime.Goexit | 12:27 |
| voidspace | rogpeppe: interesting | 12:28 |
| rogpeppe | voidspace: which is kinda like a panic | 12:28 |
| rogpeppe | voidspace: except that it doesn't actually panic | 12:28 |
| voidspace | heh | 12:28 |
| voidspace | is it "magic" implemented by the compiler, or does it use standard go mechanisms? | 12:28 |
| rogpeppe | voidspace: but if we used Assert, it wouldn't stop any of the other goroutines involved in the test | 12:29 |
| voidspace | right | 12:29 |
| rogpeppe | voidspace: runtime.Goexit is magic | 12:29 |
| rogpeppe | voidspace: as is everything in the runtime package | 12:29 |
| voidspace | heh | 12:29 |
| voidspace | ok, well maybe fair enough then | 12:29 |
| voidspace | it's "exposed magic" | 12:29 |
| voidspace | rogpeppe: so your suggested code to avoid using the channel directly when testing the batching of calls | 12:30 |
| voidspace | rogpeppe: spins up two goroutines and uses a WaitGroup | 12:31 |
| rogpeppe | voidspace: yes | 12:31 |
| voidspace | rogpeppe: but in the final assertion we're depending on the order of those calls | 12:31 |
| rogpeppe | voidspace: ah, interesting | 12:31 |
| voidspace | rogpeppe: which is strictly incorrect now I guess | 12:31 |
| rogpeppe | voidspace: yeah | 12:31 |
| rogpeppe | voidspace: you could sort 'em | 12:31 |
| voidspace | rogpeppe: sounds good | 12:31 |
| voidspace | or use a set | 12:31 |
| voidspace | what's the set type? | 12:31 |
| mgz | wouldn't sets be nice | 12:32 |
| voidspace | hah | 12:32 |
| rogpeppe | voidspace: sorting's probably a little easier | 12:32 |
| bodie_ | anyone have feeling on whether cobzr should be used? I'm new to working on launchpad stuff... | 12:32 |
| voidspace | and you can't use mappings with keys of arbitrary types, so you can't easily simulate them | 12:32 |
| bodie_ | Git kid | 12:32 |
| mgz | bodie_: I say no | 12:32 |
| mgz | but you do need some alternative setup to make go happy with its layout quirks | 12:33 |
| bodie_ | happy little quirks | 12:33 |
| bodie_ | taking the bob ross approach today | 12:33 |
| * rogpeppe quirks happily | 12:33 | |
| voidspace | quirk as a verb | 12:34 |
| voidspace | what fun | 12:34 |
| bodie_ | these kids these days with their selfies and their "quirking" | 12:34 |
| rogpeppe | voidspace: the other possibility is just to avoid asserting on the ids passed to Instances | 12:34 |
| voidspace | rogpeppe: that's the assert that the calls were batched | 12:34 |
| voidspace | rogpeppe: so I'd rather leave it in... | 12:34 |
| voidspace | rogpeppe: I could just assert that the length is two | 12:35 |
| voidspace | rogpeppe: as that's what we care about | 12:35 |
| rogpeppe | voidspace: you know that the right results have come back, so the right info has flowed through to instances; all you really care about is the number of calls to Instances (and the number of ids in those calls) | 12:35 |
| rogpeppe | voidspace: yeah | 12:35 |
| voidspace | rogpeppe: right, so the length of testGetter.ids is the relevant part | 12:35 |
| rogpeppe | voidspace: yeah | 12:35 |
| mgz | # launchpad.net/juju-core/state/apiserver/keymanager_test | 12:40 |
| mgz | state/apiserver/keymanager/keymanager_test.go:20: inconsistent definition for type gocheck.C during import | 12:40 |
| mgz | I guess that's some version skew issue... | 12:40 |
| mgz | I should godepitup | 12:40 |
| voidspace | oh yeah, if I restart the vm then my ssh sessions die too... | 12:41 |
| jam | mgz: can you help me track down a bug I just ran into ? | 12:51 |
| jam | https://bugs.launchpad.net/juju-core/+bug/1291967 | 12:51 |
| _mup_ | Bug #1291967: cannot destroy-environment with 1.17.4 of a trunk bootstrapped env "ftp-proxy" <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1291967> | 12:51 |
| jam | I think this is from thumper's changes | 12:51 |
| jam | he added some new fields, that end up being the empty string, and 1.17.4 says that is a broken environment, and prevents be from destroying it. | 12:51 |
| jam | In *itself* we don't have to be compatible with 1.17.4, but I don't want us to end up where in 1.18.0 will refuse to destroy an 1.18.1 environment. | 12:52 |
| mgz | jam: ugh, that looks bad | 12:52 |
| jam | mgz: you can ignore the Panic() I got, because I think it *might* be unrelated, but handling "empty strings treated as invalid config" is bad. | 12:53 |
| jam | I thought I saw something from axw about "allow unknown fields" | 12:53 |
| jam | mgz: I just don't have time to finish tracking it down. | 12:53 |
| jam | mgz: for extra fun times, everytime I run "juju destroy-environment" it lists a different key as being invalid. | 12:54 |
| jam | (hash map ordering? ) | 12:54 |
| mgz | okay, I'll see if I can repo | 12:57 |
| jam | mgz: thanks "go install launchpad.net/juju-core/..."; ~/dev/go/bin/juju bootstrap -e local; /usr/bin/juju destroy-environment local | 12:58 |
| jam | mgz: reproduces it here, FWIW | 12:58 |
| fwereade | mgz, jam: you are wonderful, I was just coming to undirectedly complain about exactly that | 12:58 |
| mgz | fwereade: have I ever said how much I love config? | 12:59 |
| fwereade | mgz, *everybody* loves config</deadpan> | 12:59 |
| jam | mgz, fwereade: it might also be something waigani was working on, but I don't see it in +activereviews or the recent commits to trunk | 13:03 |
| rogpeppe | mgz: i was looking at your comment on this review. https://codereview.appspot.com/72230045/ | 13:03 |
| mgz | rogpeppe: looking | 13:03 |
| rogpeppe | mgz: i wondered if you'd be able to join a hangout to talk about it | 13:04 |
| rogpeppe | mgz: as there are a few issues that i'm not sure about | 13:04 |
| mgz | rogpeppe: minially, you can just copy the extra arg junk from the other file | 13:04 |
| rogpeppe | mgz: that doesn't solve the target-release issue though | 13:05 |
| rogpeppe | mgz: which is a little more tricky | 13:05 |
| mgz | rogpeppe: do you use your canonical account fro hangouts or the other one? | 13:08 |
| rogpeppe | mgz: either. in the current one i'm using canonical | 13:08 |
| mgz | dialin' | 13:08 |
| wwitzel3 | rogpeppe: https://codereview.appspot.com/72270044/ | 13:08 |
| rogpeppe | https://plus.google.com/hangouts/_/7acpjqgade93ubac2gple0elsc?authuser=1&hl=en | 13:08 |
| rogpeppe | mgz: ^ | 13:08 |
| mgz | that's non-pasteable for me, can you invite me? | 13:09 |
| rogpeppe | mgz: it might work if you change authuser=1 to authuser=0 | 13:10 |
| mgz | rogpeppe: as in, it's a pain to type out a url that long | 13:10 |
| rogpeppe | mgz: ok, np | 13:10 |
| mgz | ubuntu on arm doesn't do hangouts | 13:10 |
| rogpeppe | mgz: one mo | 13:10 |
| rogpeppe | mgz: https://plus.google.com/hangouts/_/canonical.com/juju-core?authuser=1 | 13:11 |
| rogpeppe | mgz: that's the standup hangout | 13:11 |
| jam | rogpeppe: mgz's IRC machine is a different machine than his Google Hangout machine | 13:11 |
| rogpeppe | i couldn't work out how to invite people :-) | 13:11 |
| rogpeppe | mgz: https://codereview.appspot.com/72270044/ | 13:15 |
| natefinch | rogpeppe: I figured out some of the problems I was having with bootstrapping, which then let me actually test my code, and now I realize there's a problem... the bootstrap command on the bootstrap node tries to connect to state before it starts the machine agent, and since the machine agent is now the one starting mongod, things don't work. | 13:24 |
| rogpeppe | wwitzel3: are you around to join a hangout? | 13:25 |
| fwereade | natefinch, the machine agent can handle starting up with mongod already there, though, right? | 13:25 |
| marcoceppi | why are we depricating the -e flag for destroy-environment? | 13:25 |
| wwitzel3 | rogpeppe: yep | 13:25 |
| rogpeppe | marcoceppi: an excellent question :-) | 13:25 |
| rogpeppe | wwitzel3: https://plus.google.com/hangouts/_/canonical.com/juju-core | 13:25 |
| fwereade | natefinch, it *should* just be a matter of doing it in bootstrap as well, right? | 13:25 |
| natefinch | fwereade: yeah, we can do it there, too, that's a good point | 13:26 |
| marcoceppi | rogpeppe: just got a warning about using destroy-environment with the -e flag | 13:27 |
| natefinch | marcoceppi, rogpeppe: I don't think we need to deprecate the flag, it's just optional | 13:27 |
| marcoceppi | also, rogpeppe juju bootstrap doesn't take a positional environemtn, it's like the only one that does | 13:27 |
| natefinch | marcoceppi, rogpeppe: what's not optional is the environment name | 13:27 |
| marcoceppi | natefinch: I'll file a bug about the user wraning then | 13:27 |
| bodie_ | What is the point of this line in addmachine_test.go? it seems redundant | 13:43 |
| bodie_ | http://paste.ubuntu.com/7084701/ | 13:43 |
| voidspace | I assume that the following does ten iterations | 13:43 |
| voidspace | for i := 0; i < 10; i++ { | 13:43 |
| voidspace | and not 9 | 13:43 |
| natefinch | voidspace: yes. Just like in every other language :) | 13:45 |
| voidspace | natefinch: I normally use languages with less opaque loop syntax ;-) | 13:45 |
| natefinch | voidspace: I thought you did .Net stuff? isn't that the exact same syntax? | 13:46 |
| voidspace | natefinch: that was about six years ago! | 13:46 |
| voidspace | but yes | 13:46 |
| natefinch | voidspace: ahh | 13:46 |
| natefinch | voidspace: I went C -> C++ -> C#, so it's the exact same syntax I've used since I started programming | 13:46 |
| voidspace | maybe only five | 13:46 |
| bodie_ | today I learned: for loop is opaque | 13:46 |
| bodie_ | kids these days | 13:47 |
| voidspace | if you weren't a programmer, what would this mean: "for i := 0; i < 10; i++" | 13:47 |
| bodie_ | find a programmer | 13:47 |
| bodie_ | :D | 13:47 |
| voidspace | "for i in range(10)" I reckon even my non-programmer friends could hazard a guess... | 13:47 |
| bodie_ | hmm, good point | 13:47 |
| natefinch | bodie_: the thing I think is funny is the people complaining about having to write 3 line loops instead of having some magic one liner to do the exact same thing | 13:47 |
| voidspace | natefinch: well, it depends on the level of magic | 13:48 |
| bodie_ | one line + {} = 3 lines | 13:48 |
| voidspace | natefinch: I do love list comprehensions | 13:48 |
| voidspace | natefinch: and Go *could* gain slice comprehensions | 13:49 |
| natefinch | voidspace: very very simple ones are ok, but they tend to get abused into huge monstrosities | 13:49 |
| natefinch | voidspace: line returns are not evil :) | 13:49 |
| bodie_ | list comps are swanky, i'll give ya that | 13:49 |
| voidspace | natefinch: well, no - but you can write bad code with every construct | 13:49 |
| voidspace | natefinch: so I never find "but people write bad code" a very convincing argument in itself | 13:50 |
| natefinch | voidspace: yes, but some constructs encourage hard to read code, and some discourage it | 13:50 |
| voidspace | natefinch: and yes, I always break up large comprehensions into an explicit loop | 13:50 |
| bodie_ | you have to admit syntax like x = [i*i for i in x] is pretty handy | 13:50 |
| voidspace | loop and filter in a single expression is nice - especially that it is an expression | 13:50 |
| voidspace | f(x for x in y if x) | 13:51 |
| bodie_ | I hail from the mystical land of Perl so I'm definitely a little bit twisted in the head | 13:51 |
| bodie_ | I mean, there are ungainly list comprehensions, and then there's Perl... | 13:51 |
| natefinch | bodie_: your poor poor soul | 13:51 |
| voidspace | natefinch: I do like that Go is small, it certainly makes it easier to learn | 13:51 |
| voidspace | except the "you don't need to care about pointers except when you need to care about pointers" | 13:51 |
| voidspace | I foxed Martin with that yesterday and I'm *pretty sure* the same code also mildly foxed Roger in his review :-) | 13:52 |
| voidspace | he suggested changing a slice of pointers to a slice of "non-pointers" but I don't think we can do that because we need pointer receivers | 13:53 |
| natefinch | voidspace: the smallness of go is hugely handy. There's no "Oh crap, let's go look up how <somekeyword> works | 13:54 |
| bodie_ | that is something I really appreciate | 13:54 |
| bodie_ | as a relative newcomer | 13:54 |
| voidspace | I *bet* Go in five years is substantially bigger though (although not to the extent of other languages I'm sure) | 13:55 |
| natefinch | voidspace: C# was well into that territory when I left. They basically threw everything in there. Dynamic types? Sure! Contracts? Sure! Async calls? Sure! | 13:55 |
| natefinch | voidspace: I don't know... it's one of their core tenants to keep the language small | 13:55 |
| voidspace | natefinch: the C# full language spec was *already* huge when I started with it in 2006 | 13:55 |
| voidspace | natefinch: I like that they're very conservative | 13:55 |
| voidspace | natefinch: but I'd stiill wager good money | 13:55 |
| voidspace | *still even | 13:55 |
| natefinch | voidspace: it'll be bigger, I don't know about substantially bigger. I think they're pretty happy keeping it small, and there's not a lot that's missing other than generics. Most everything else is just syntactic sugar | 13:56 |
| voidspace | yeah, when generics arrive it will be nice | 13:57 |
| voidspace | but who doesn't like things just that little bit sweeter - it's *very* hard to resist the call altogether | 13:57 |
| natefinch | voidspace: I don't know.... they're some pretty grumpy old unix guys. They don't even like syntax highlighting in their editors :) | 13:57 |
| voidspace | :-) | 13:57 |
| natefinch | voidspace: I bet we'll see a lot of improvements to the performance and behavior, a lot of improvements in tooling - they're talking about building their own debugger, because GDB isn't a good fit for Go... that's the one thing I'd love to have, is a better debugger. | 13:58 |
| voidspace | natefinch: a real repl would be good too | 14:00 |
| voidspace | anyway, I stand by my claim (five years is an age in programming - even going really slowly a lot can change). But we'll see. | 14:01 |
| bodie_ | I'm not sure how I feel about a gorepl | 14:02 |
| bodie_ | it's so trivially quick to compile and so small that it doesn't feel like I have an excuse to want one | 14:02 |
| natefinch | voidspace: real repls in compiled languages are tricky. .Net can sorta do it because it's compiled to an intermediary form, but for truly native code, it's tricky. Being able to query values is usually enough... being able to change them is really nice, but might not be feasible | 14:02 |
| voidspace | natefinch: right | 14:02 |
| natefinch | bodie_: it helps a lot when you're 5 minutes into a 10 minute bootstrap and something fails | 14:03 |
| bodie_ | word | 14:03 |
| voidspace | natefinch: but the support you need for a repl and the support you want for a debugger are not so different | 14:03 |
| bodie_ | I was actually looking at the bug for lxc-clone | 14:03 |
| natefinch | voidspace: true | 14:03 |
| bodie_ | I think that would be really handy, but I'm not too sure where to start | 14:03 |
| natefinch | voidspace: there are some go repls out there.... basically recompile after each line you enter, which is kind cool. I haven't tried them, though, since it's usually pretty trivial to do the recompile yourself | 14:04 |
| bodie_ | https://bugs.launchpad.net/juju-core/+bug/1203291 | 14:04 |
| _mup_ | Bug #1203291: local provider moar awesome with lxc-clone <local-provider> <papercut> <performance> <juju-core:Triaged> <https://launchpad.net/bugs/1203291> | 14:04 |
| bodie_ | ^ that one | 14:04 |
| voidspace | natefinch: yeah, although the compiler really fights against you I guess | 14:04 |
| voidspace | natefinch: unused variables, unimported modules | 14:05 |
| voidspace | although all those are fixable with code transforms (automatically generate the imports and fake out the variable usage) | 14:05 |
| bodie_ | I think that what seems finicky about Go on the surface (grumpy compiler) is actually really useful for figuring out what's wrong with my code | 14:05 |
| voidspace | yeah, proper compile errors can be great | 14:06 |
| natefinch | the modules thing you can get around... usually it's just fmt that comes and goes, so you can do var _ = fmt.Printf and it'll be quiet | 14:06 |
| voidspace | but they can also make exploratory coding and writing tests harder | 14:06 |
| bodie_ | heh... emphasis on proper | 14:06 |
| natefinch | THere's definitely been times when the unused variables error has shown me a bug in my code | 14:07 |
| bodie_ | maybe a linter that runs on every update would be handy, something like what's in gosublime | 14:07 |
| bodie_ | although the compile is already so snappy | 14:07 |
| voidspace | natefinch: makes a great typo catcher | 14:07 |
| bodie_ | you could also write a hook to build on save | 14:07 |
| bodie_ | but again slightly too involved | 14:07 |
| voidspace | flake8 does the same for Python - it's the most trivial kind of thing to catch | 14:08 |
| natefinch | there's a gofmt variant that'll automatically add/remove imports | 14:08 |
| voidspace | yep, rogpeppe mentioned that - sounds useful | 14:08 |
| natefinch | bodie_: one thing you can check out is that gofmt will only modify the code if it has proper syntax, so if you save and it doesn't gofmt, you know there's a compile error. It doesn't catch *all* errors, but it catches many. | 14:08 |
| bodie_ | neat :) | 14:11 |
| bodie_ | what do you think of golint? | 14:11 |
| natefinch | bodie_: I haven't tried it | 14:11 |
| bodie_ | I think it's nice | 14:12 |
| natefinch | oh, one more cool thing gofmt does is space out your code according to order of operations, so 5 + 7 / 2 + 8 gets formatted into 5 + 7/2 + 8 to make it more obvious what actually will happen | 14:12 |
| bodie_ | that is cool | 14:12 |
| natefinch | that also saved me a hard to find bug | 14:13 |
| mgz | (+ 5 (/ 7 2) 8) | 14:17 |
| * natefinch scowls at mgz | 14:18 | |
| natefinch | fwereade: of course, making bootstrap create mongo is easy.... *testing* that it does so is a PITA | 14:22 |
| voidspace | gc.LessThan? | 14:22 |
| natefinch | voidspace: does it not exist? If not, look for it in juju-core/testing/checkers | 14:24 |
| voidspace | I was asking if it exists - I assume it does | 14:24 |
| natefinch | voidspace: try it and find out :) | 14:24 |
| voidspace | the compiler won't tell me because I'm making an assert on a member that I haven't yet written | 14:24 |
| voidspace | the compiler will tell me in a minute | 14:24 |
| voidspace | once I fix my syntax errors! | 14:24 |
| natefinch | heh | 14:24 |
| natefinch | voidspace: autocomplete? | 14:25 |
| voidspace | natefinch: not yet | 14:25 |
| voidspace | hopefully at the weekend or when I get a spare hour or two I will get vim properly configured | 14:25 |
| voidspace | and work out why godef isn't working properly for me | 14:25 |
| voidspace | etc | 14:25 |
| natefinch | voidspace: ahh, sadface. | 14:25 |
| voidspace | gc.LessThan does not exist the compiler tells me | 14:26 |
| rogpeppe | 5 7 2 / + 8 + | 14:26 |
| rogpeppe | voidspace: it's in testing/checkers | 14:27 |
| voidspace | rogpeppe: checkers.LessThan ? | 14:27 |
| voidspace | rogpeppe: thanks, I will look anyway | 14:27 |
| rogpeppe | voidspace: yeah, although we usually import it as jc | 14:27 |
| natefinch | voidspace: the convention is to import the package as jc (to mirror gc for gocheck) | 14:27 |
| voidspace | natefinch: cool | 14:28 |
| voidspace | js.Saves | 14:28 |
| voidspace | *jc.Saves dammit | 14:28 |
| natefinch | voidspace: it's not a pointer type | 14:28 |
| * natefinch ducks | 14:28 | |
| voidspace | :-) | 14:29 |
| voidspace | rogpeppe: so the batch test passes | 14:30 |
| voidspace | rogpeppe: but I couldn't remember what type you suggested for the counter, so I just incremented an int | 14:30 |
| voidspace | rogpeppe: can you remind me please | 14:31 |
| voidspace | rogpeppe: make 100 requests, wait for them to complete | 14:31 |
| voidspace | ah, we probably only made 2 calls, I need a pause in between calls | 14:31 |
| adeuring | thedac: could you have a look at my comment in bug 1243827? I have doubt that using double underscores ever worked | 14:31 |
| _mup_ | Bug #1243827: juju is stripping underscore from options <canonical-webops> <config> <goyaml:In Progress by adeuring> <juju-core:Invalid by adeuring> <juju-deployer:Invalid by hazmat> <https://launchpad.net/bugs/1243827> | 14:31 |
| mramm | core rep on the cross team meeting? | 14:33 |
| mramm | fwereade: rogpeppe: dimitern: ^^^^ | 14:34 |
| dimitern | mramm, if possible, i'd like to skip it to finish of the 2 critical bugs i'm working on | 14:35 |
| thedac | adeuring: hi, I orginally submitted that bug thinking it was against juju-deployer. In that context (a juju deployer config) using the doubled underscores worked. I have never tested that with juju core by itself. Also see jacekn's exampel of nagios_check_https_params: "-H 127.0.0.1 --ssl -p {https_port}" Would this include strings that begin with '-'? | 14:35 |
| natefinch | mramm: I can get on it if others aren't available | 14:36 |
| mramm | looks like william is on it | 14:38 |
| natefinch | awesome | 14:38 |
| voidspace | lunch | 14:39 |
| * voidspace lurches | 14:39 | |
| * rogpeppe is also lunching | 14:40 | |
| * natefinch reboots | 14:43 | |
| adeuring | thedac: yes, it's about strings that start with a '+', '-' or a digit. And thanks for confirming that using double undescores in juju-deployer worked as a workaround. Seems that I need tro dig a bit deeper to avoid possible upgrade problems... | 14:44 |
| * thedac nods | 14:45 | |
| natefinch | is it bad that I want to change the font in my editor because my : and = don't line up nicely? | 15:03 |
| mgz | natefinch: surely having them not line up well is a feature | 15:06 |
| mgz | make it stick out more | 15:06 |
| TheMue | natefinch: as long as the reboot hasn't been needed due to the font change ;) | 15:06 |
| natefinch | bodie_: btw, about colocated branches for bzr & go... I think it's really the only sane way to code in go, but others appear to disagree with me. | 15:07 |
| natefinch | TheMue: haha, no, just updates | 15:07 |
| natefinch | mgz: I guess I can know that whenever I get that twitch in my eye, it's because I'm looking at := rather than just = | 15:07 |
| mgz | exactly! | 15:07 |
| natefinch | mgz: ironically, the non-monospaced ubuntu font (which I use in IRC) lines them up quite nicely, but the monospaced version does not | 15:08 |
| natefinch | mgz: I merged some changes from trunk, and forgot I had some local changes, too. Is there any way to separate out the merge from my local changes? | 15:10 |
| mgz | natefinch: it's a little painful unfortunately | 15:11 |
| mgz | as it's a diff-on-diff operation | 15:11 |
| mgz | try just doing `bzr shelve` and shelving your local changes | 15:11 |
| mgz | then commiting the (cleaned) merge | 15:12 |
| mgz | 2014-03-13 15:24:42 ERROR juju runner.go:220 worker: exited "environ-provisioner": no state server machines with addresses found | 15:26 |
| mgz | ~hm... | 15:26 |
| rogpeppe | voidspace: how is lbox propose failing for you? i have a few inline comments i'd like to make | 15:26 |
| mgz | that's not something I wanted to see with a fresh bootstrap --upload-tools on trunk | 15:26 |
| natefinch | mgz: yuck | 15:31 |
| rogpeppe | mgz: hmm, that's not good | 15:40 |
| natefinch | bbiab, picking up my daughter from preschool | 15:41 |
| mgz | rogpeppe: how should I manually restart it to see if it'll work now | 15:41 |
| rogpeppe | mgz: manually restart what? | 15:41 |
| mgz | oh, it did it | 15:41 |
| mgz | or at least status now says started, not down | 15:42 |
| rogpeppe | mgz: without a bit more context i'm not sure i can help | 15:47 |
| mgz | rogpeppe: when I first ran bootstrap just then, `juju status` reported the agent-state of machine-0 was down | 15:48 |
| mgz | last line in machine-0.log was that | 15:48 |
| mgz | but rechecking just then, nothing else in log, but agent-state was started | 15:48 |
| rogpeppe | mgz: hmm, odd | 15:49 |
| rogpeppe | mgz: i'm not entirely surprised by seeing the machine as down | 15:49 |
| mgz | so, presumably it got to a point where it could find its own address and the worker restarted okay | 15:49 |
| rogpeppe | mgz: but i'd have thought there would always be an address in machine 0 | 15:49 |
| mgz | yeah | 15:49 |
| mgz | I'd also expect more log after it came back up... | 15:49 |
| rogpeppe | mgz: that doesn't surprise me | 15:50 |
| rogpeppe | mgz: the started status is mediated by the presence poller | 15:50 |
| rogpeppe | mgz: the environ-provisioner exiting shouldn't cause the whole machine agent to go down | 15:51 |
| rogpeppe | mgz: or even the API worker | 15:51 |
| rogpeppe | mgz: was the "worker: exited" line the very last line in the log? | 15:51 |
| mgz | rogpeppe: yes | 15:55 |
| voidspace | rogpeppe: sorry, just seen your message | 15:55 |
| voidspace | rogpeppe: pastebin about to follow | 15:55 |
| voidspace | maybe I just need to merge trunk again | 15:56 |
| voidspace | it's the branch check that is failing | 15:56 |
| rogpeppe | voidspace: the branch check? | 15:56 |
| voidspace | rogpeppe: https://pastebin.canonical.com/106421/ | 15:56 |
| rogpeppe | mgz: usually the Runner code prints "restarting "..." in 3s" immediately after the worker: exited msg | 15:57 |
| voidspace | brb | 15:57 |
| rogpeppe | voidspace: looks like it's found a genuine error in your code | 15:57 |
| mgz | rogpeppe: that's not his code, it's trunk | 15:58 |
| rogpeppe | mgz: ah, well it's bogus anyway, and shouldn't have got through govet | 15:59 |
| rogpeppe | mgz: i suspect whoever committed the code has disabled govet | 15:59 |
| mgz | 2366.14.2 tim.pen | logger.Errorf("unexpected output: ", out) | 15:59 |
| mgz | so, real issue, but a pre-existing one | 16:00 |
| rogpeppe | mgz: yeah - i think tim has disabled govet | 16:00 |
| rogpeppe | voidspace: you'll need to fix that before proposing your branch | 16:00 |
| mgz | I try to disable all things containing gove | 16:01 |
| rogpeppe | voidspace: it should be logger.Errorf("unexpected output: %s", out) | 16:01 |
| voidspace | rogpeppe: I'll fix that and propose then | 16:02 |
| mgz | or %q arguably | 16:02 |
| rogpeppe | mgz: +1 | 16:02 |
| rogpeppe | voidspace: ^ | 16:02 |
| voidspace | rogpeppe: mgz yep | 16:02 |
| mgz | voidspace: so, you can just `bzr switch trunk; bzr switch -b fixtim` ...edit...commit...propose... | 16:03 |
| voidspace | mgz: too late, I fixed in my branch and started the lbox propose already | 16:04 |
| voidspace | mgz: I mean, I could submit *another* branch for trunk with the same fix | 16:04 |
| mgz | never mind then :) | 16:04 |
| voidspace | there's another bug in clonetemplate.go too | 16:05 |
| voidspace | *mockContainer does not implement golxc.Container (wrong type for Clone method) | 16:05 |
| voidspace | who merged this... | 16:05 |
| mgz | bzr blame! | 16:05 |
| mgz | check you have your godeps right | 16:06 |
| mgz | several tips are not compatible with juju-core atm | 16:06 |
| voidspace | mgz: I haven't changed my deps | 16:08 |
| voidspace | mgz: aren't we pinning our deps anyway? | 16:08 |
| mgz | voidspace: yes, but that requires some active work when other people change things | 16:08 |
| rogpeppe | voidspace: try (from the juju-core root) godeps -u *.tsv | 16:09 |
| mgz | voidspace: run `godeps -u dependencies.tsv` from inside the juju-core dir | 16:09 |
| voidspace | interesting | 16:09 |
| voidspace | godeps: cannot update "/home/michael/canonical/src/launchpad.net/golxc": bzr: ERROR: branch has no revision tim.penhey@canonical.com-20140311005930-b14361bwnocu3krh | 16:09 |
| rogpeppe | voidspace: if it fails, you'll have to manually go get -u the packages that it fails for | 16:09 |
| mgz | it may well complain that it doesn't... right, that | 16:09 |
| rogpeppe | voidspace: yeah | 16:09 |
| rogpeppe | voidspace: go get -u launchpad.net/golxc | 16:10 |
| rogpeppe | voidspace: then try again | 16:10 |
| mgz | `pushd ../golxc; bzr pull; popd` also works | 16:10 |
| rogpeppe | voidspace: blame me for not integrating pull support into godeps | 16:10 |
| voidspace | rogpeppe: ah... :-) | 16:10 |
| voidspace | so we just pull the branch and then we can update to the required revision | 16:11 |
| rogpeppe | voidspace: yeah | 16:11 |
| mgz | yup | 16:11 |
| voidspace | that may well have fixed the other issues | 16:11 |
| voidspace | trying | 16:11 |
| voidspace | thanks guys | 16:11 |
| rogpeppe | mgz: presumably that was a reference to a conservative MP then... | 16:11 |
| * rogpeppe is very slow | 16:12 | |
| mgz | :P | 16:12 |
| voidspace | yup, working | 16:12 |
| voidspace | rogpeppe: CL updateed | 16:13 |
| voidspace | *updated even | 16:13 |
| rogpeppe | voidspace: that int type i was suggesting was int32 - use atomic.AddInt32 to increment it | 16:13 |
| rogpeppe | voidspace: cool | 16:13 |
| voidspace | rogpeppe: ah, thanks | 16:13 |
| voidspace | I will make that change after coffee | 16:14 |
| hatch | Hey is anyone working on an nginx charm yet ? | 16:19 |
| rogpeppe | voidspace: reviewed | 16:33 |
| voidspace | rogpeppe: I don't think we can use []instance.Instance | 16:33 |
| rogpeppe | voidspace: no? | 16:33 |
| voidspace | rogpeppe: they need to be created as pointers for the pointer receivers | 16:33 |
| voidspace | we already tried it IIRC | 16:33 |
| rogpeppe | voidspace: i think it should work fine | 16:34 |
| voidspace | rogpeppe: I think it didn't :-) | 16:34 |
| voidspace | but I will try again | 16:34 |
| rogpeppe | voidspace: you're assigning *testInstance to instance.Instance | 16:34 |
| rogpeppe | voidspace: so []instance.Instance{instance1} should work ok | 16:34 |
| mgz | rogpeppe: we need to use testInstance as instance.Instance - which requires a pointer unless I'm confused about something | 16:34 |
| rogpeppe | voidspace: when instance1 is a *testInstance | 16:34 |
| rogpeppe | mgz: instance.Instance is an interface | 16:35 |
| rogpeppe | mgz: it can hold a concrete type that's a pointer | 16:35 |
| mgz | right, what you said then is fine... there was something in the earlier review that was different | 16:35 |
| rogpeppe | mgz: the only reason it might not be a great idea is if you wanted to access the results slice after creating it and avoid the dynamic type conversion | 16:36 |
| mgz | (or I misread) | 16:36 |
| rogpeppe | mgz: but the code doesn't do that AFAICS | 16:36 |
| voidspace | rogpeppe: mgz: so it looks like it's working | 16:37 |
| voidspace | changing all the uses... | 16:37 |
| rogpeppe | voidspace: thanks | 16:37 |
| rogpeppe | voidspace: kinda trivial i know, but worth doing i think | 16:38 |
| natefinch | interfaces are already pointer-ish, so you almost never need a pointer to an interface | 16:38 |
| voidspace | natefinch: sure, it's just the concrete types you have to worry about | 16:39 |
| voidspace | although that maybe the same... | 16:39 |
| voidspace | what I didn't know that a pointer to an "instance" (term?) of a concrete type would satisfy an Interface type requirement | 16:40 |
| natefinch | voidspace: yeah.. one of the things that took some time for me to wrap my head around was pointer receivers.... what helped me was to think of the pointer to a type as being a totally separate type than the non-pointer value | 16:40 |
| voidspace | natefinch: right | 16:40 |
| voidspace | natefinch: that's not the confusion in this case - we *knew* we needed a pointer to the type because of the pointer receiver | 16:40 |
| natefinch | voidspace: epseically true for pointers to type fulfilling interfaces | 16:40 |
| voidspace | what we didn't know was that we could then use []Interface instead of []*ConcreteType | 16:40 |
| natefinch | voidspace: ahh yeah | 16:41 |
| natefinch | the way I think of it is that an interface is really just a special struct that gets automatically wrapped around a pointer to the concrete type (and in fact, that's really what they are) | 16:42 |
| voidspace | natefinch: so something declared as being of type Interface will *always* be a pointer? | 16:43 |
| natefinch | voidspace: an interface is a struct that holds the type and either a pointer to the value, or the value itself if the value fits in an int64 (the latter applies to pointers to concrete types) | 16:44 |
| voidspace | natefinch: so, for a concrete type, to know if it's a pointer or not you need to know the struct layout in memory? | 16:45 |
| natefinch | voidspace: yeah, but it doesn't actually matter if it gets a pointer to the value or not. Methods are called on the underlying type the same way. | 16:46 |
| natefinch | remember that "type" in this case might be "struct" or "pointer to struct" | 16:46 |
| voidspace | natefinch: does it *never* make any difference - using an Interface abstracts that away completely? | 16:46 |
| voidspace | I initially want to build up a mental model of how to use the language, and I'll *then* work on a mental model of what it's doing under the hood | 16:47 |
| natefinch | yes, because the type you pass in has to fulfill the interface. So calling Foo() on the interface is the same as calling Foo() on whatever you passed in. | 16:47 |
| voidspace | although I realise that the two are inextricable entwined | 16:47 |
| natefinch | the only reason it matters that an interface might hold a pointer to your type is that you then know that passing around an interfacve is cheap, since it's just passing a few bytes of data, even if the underlying type is huge | 16:48 |
| voidspace | right | 16:48 |
| voidspace | the classic difference between value and reference types | 16:49 |
| voidspace | so an interface is always a reference type | 16:49 |
| hazmat | fwereade, did you want to talk about permission denied | 16:49 |
| hazmat | fwereade, i added some additional info to the bug report | 16:49 |
| fwereade | hazmat, possibly, I'm trying to repro now, I'll take another look at the bug report | 16:49 |
| natefinch | voidspace: yeah | 16:49 |
| natefinch | voidspace: same with maps, slices, and channels | 16:50 |
| voidspace | right | 16:50 |
| voidspace | interesting | 16:50 |
| voidspace | but not arrays | 16:50 |
| voidspace | where you can't even take a pointer to it, right? | 16:50 |
| fwereade | hazmat, I see nothing new in https://bugs.launchpad.net/juju-core/+bug/1279018 or https://bugs.launchpad.net/juju-core/+bug/1239681 | 16:51 |
| _mup_ | Bug #1279018: relation-departed hook does not surface the departing relation-data to related units <landscape> <relations> <juju-core:Triaged> <https://launchpad.net/bugs/1279018> | 16:51 |
| _mup_ | Bug #1239681: relation-get failing with 'permission denied' <landscape> <regression> <juju-core:Triaged by fwereade> <postgresql (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1239681> | 16:51 |
| natefinch | arrays are just sequential memory, so when you copy them you copy the whole dang thing. You can get a pointer to an array, that's how slices work behind the scenes. | 16:51 |
| hazmat | fwereade, the pastebin link from 3/5 | 16:51 |
| hazmat | fwereade, http://paste.ubuntu.com/7041709/ | 16:51 |
| fwereade | hazmat, ah, sorry, I saw that earlier | 16:51 |
| natefinch | voidspace: the number of times I've had to interact with arrays in over a year of programming in Go is exactly zero, though. | 16:51 |
| voidspace | natefinch: hah, cool | 16:52 |
| hazmat | fwereade, i was debugging with them via irc in debug-hooks.. all 1.17.5.. could do relation-ids, see all the rel data minus the problematic one. | 16:52 |
| natefinch | voidspace: one of the things I like about go is that the memory model is very easy to understand. It's easy to know how big a struct is, so you can know how much memory you're using, what it costs to pass around, etc. And yet, it doesn't interfere with actually *using* the language. | 16:54 |
| voidspace | natefinch: that's good to hear | 16:54 |
| fwereade | hazmat, I will keep trying to repro and come crying to you if I can't -- what I currently see is old relation settings still accessible despite that relation not even being in relation-list (as expected, because departing) | 16:56 |
| hazmat | fwereade, i'm trying to get the partner to publish their charms as they've got very reproducible issue there.. alternatively i guess i can write some charms to help.. landscape team was also running into this issue | 16:57 |
| hazmat | fwereade, i think you mean s/relation-list/relation-ids / | 16:57 |
| voidspace | mramm: do we have any open positions at the moment? I know a superlative candidate... | 16:57 |
| * rogpeppe pores over a 167MB log file, looking for the needle | 16:57 | |
| fwereade | hazmat, I meant to say "unit not even being in relation-list" | 16:58 |
| natefinch | voidspace: pretty sure we still have open spots | 16:58 |
| fwereade | hazmat, if the *relation* is not in relation-*ids* that's interesting | 16:58 |
| hazmat | fwereade, the relation id is in relation-ids.. the issue is just relation-get against it | 16:59 |
| fwereade | hazmat, it's always relation-get against a specific unit as well though | 16:59 |
| hazmat | fwereade, note ... this isn't failing accessing remote units.. but self unit | 16:59 |
| hazmat | afaics | 17:00 |
| hazmat | although the ls bug was specifically against remote units | 17:00 |
| fwereade | hazmat, *self* I had not spotted -- that paste didn't seem to be accessing self specifically | 17:01 |
| fwereade | hazmat, I don't actually see any self accesses there... | 17:02 |
| hazmat | hmm.. i guess not | 17:02 |
| rogpeppe | voidspace: when you do feel you want a better handle on what's going under the surface (i find it's very useful for understanding operation costs), these two articles are great: http://research.swtch.com/godata http://research.swtch.com/interfaces | 17:02 |
| voidspace | rogpeppe: cool, will bookmark | 17:02 |
| hazmat | fwereade, i'll see if i can come up with something self-contained to reproduce tomorrow. | 17:03 |
| natefinch | rogpeppe: thanks, I'm sure he explains it better than me :) | 17:04 |
| fwereade | hazmat, still failing to repro... have done everything I can think of to trigger it in both peer and pro/req relations... if you can find something that would be great | 17:08 |
| wwitzel3 | is there any known issues with the machineconfig tests? I'm getting a bunch of timeout debug messages and then a PANIC during TearDownTest | 17:09 |
| wwitzel3 | http://paste.ubuntu.com/7085765/ | 17:11 |
| natefinch | wwitzel3: the known issues are that sometimes it does that. At least, that's one of the known issues. For some people it works fine, for some people (like me) it fails all the time. | 17:15 |
| wwitzel3 | natefinch: great | 17:15 |
| natefinch | wwitzel3: which is ironic, because I wrote most of those tests :/ | 17:15 |
| wwitzel3 | natefinch: must be an timezone thing | 17:15 |
| wwitzel3 | :P | 17:15 |
| wwitzel3 | natefinch: I deleted all of my gocheck folders in /tmp and it passed for me | 17:18 |
| voidspace | rogpeppe: can you look at this and see if you think it's acceptable | 17:19 |
| voidspace | https://pastebin.canonical.com/106435/ | 17:19 |
| voidspace | rogpeppe: I left the GreaterThan assert in, otherwise doing it all in one call would pass - we expect a minimum of 11 calls | 17:19 |
| natefinch | wwitzel3: interesting | 17:20 |
| rogpeppe | voidspace: thinking | 17:20 |
| rogpeppe | voidspace: with some really weird scheduling decisions, i could see that it might possibly give less than 11 calls, but i think it's probably safe to assume that won't happen | 17:23 |
| voidspace | rogpeppe: you mean if the code blocks inside the call to Instances so that more than ten requests queue up | 17:23 |
| rogpeppe | voidspace: yeah | 17:24 |
| voidspace | rogpeppe: right, I'd be inclined to leave it in the test and just bump it down if it's flaky | 17:24 |
| rogpeppe | voidspace: sgtm | 17:24 |
| voidspace | coolio | 17:24 |
| mramm | voidspace: we do | 17:30 |
| mramm | 6+3 open positions on core and JAAS teams | 17:30 |
| mramm | so plenty ;) | 17:31 |
| voidspace | mramm: can you send me links to the core ones and I'll send excellent candidates your way | 17:31 |
| voidspace | mramm: or are they easy to deduce from talebo? | 17:31 |
| voidspace | if they're marked juju-core I'll find them | 17:31 |
| mramm | should be easy do deduce | 17:31 |
| mramm | but I'll find them quick | 17:31 |
| wwitzel3 | mgz: https://codereview.appspot.com/72270044/ | 17:31 |
| mgz | wwitzel3: thanks | 17:32 |
| mramm | https://ch.tbe.taleo.net/CH03/ats/careers/requisition.jsp?org=CANONICAL&cws=1&rid=743 | 17:32 |
| voidspace | mramm: thanks | 17:33 |
| mramm | shoot me an e-mail too | 17:33 |
| voidspace | mramm: coolio | 17:35 |
| voidspace | will promote wildly on twitter just for the hell of it | 17:35 |
| voidspace | mramm: I'll only email you about people I actually know though, the rest can just apply normally | 17:36 |
| mramm | voidspace: cool, thanks | 17:36 |
| mgz | mramm: did you do another round of travel approval approving? | 17:37 |
| mramm | mgz: not yet | 17:37 |
| * mgz patientlies | 17:38 | |
| wwitzel3 | mgz: you want to hangout while you review that? | 17:42 |
| wwitzel3 | mgz: so you can point and laugh at me in real time | 17:42 |
| mgz | sure | 17:43 |
| natefinch | I need a way to filter my contacts on linked in by people who *haven't* started a new job in the last 8 months.... because that would filter out like 90% of my contacts | 17:56 |
| bodie_ | yeah, the job market is a massive game of musical chairs right now, it seems like | 17:58 |
| dstroppa | fwereade: when I bootstrap with --upload-tools I get the same error as in the tests. I I force to get to tools .tgz file from streams.canonical.com then I get passed that point | 18:03 |
| dstroppa | fwereade: so it looks like it something with the uploaded tools | 18:03 |
| bodie_ | I think I'm doing something wrong here, I ran go test launchpad.net/juju-core and it completed in 0.002s | 18:07 |
| bodie_ | is there some other way I'm supposed to do this? | 18:07 |
| bodie_ | I'm pretty new to the ecosystem | 18:07 |
| natefinch | bodie_: go test ./... | 18:08 |
| bodie_ | thanks | 18:08 |
| natefinch | bodie_: go test either tests the package in this directory, or takes the path of a package, where ... is a wildcard that matches everything. Basically that will just run tests in this directory and all subdirectories | 18:09 |
| natefinch | bodie_: that's 99% of the use I've had for it, but in theory you can do like .../foo/... and test everything with /foo/ in the path | 18:11 |
| wwitzel3 | natefinch: https://codereview.appspot.com/72270044/ when you get a chance :) | 18:13 |
| bodie_ | natefinch, thanks for the info :) | 18:14 |
| natefinch | bodie_: welcome. Works for go build, too | 18:16 |
| natefinch | wwitzel3: ok | 18:17 |
| dstroppa | fwereade: also updated bug #1285803 | 18:18 |
| _mup_ | Bug #1285803: [Joyent Provider] metadata mismatch when testing again Joyent Public Cloud <joyent-provider> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1285803> | 18:18 |
| rogpeppe | voidspace: ready to land with one tiny fix | 18:27 |
| bodie_ | I guess I need to have a juju stateservice running to run tests, right? | 18:27 |
| natefinch | bodie_: go test does everything it needs to run tests, no external actions needed | 18:28 |
| bodie_ | hm | 18:28 |
| natefinch | good lord we have a lot of files called bootstrap.go :/ | 18:29 |
| jcastro | does anyone know where kvm support is documented? | 18:32 |
| jcastro | I'm not finding it in `juju help deploy` | 18:32 |
| * Makyo is away: Lunch | 18:33 | |
| natefinch | jcastro: juju help add-machine has lxc, but interestingly says we don't support other containers | 18:34 |
| natefinch | jcastro: juju help constraints mentions the container constraint | 18:34 |
| natefinch | (and kvm) | 18:34 |
| natefinch | jcastro: seems like we should have a juju help containers | 18:35 |
| voidspace | rogpeppe: awesome, thanks | 18:35 |
| rogpeppe | voidspace: thanks for bearing with me :-) | 18:35 |
| jcastro | ok, and if someone has an existing KVM infrastructure they would just use the manual provider right? | 18:35 |
| voidspace | rogpeppe: I've learned a lot | 18:36 |
| voidspace | rogpeppe: most of which was even useful ;-) | 18:36 |
| rogpeppe | voidspace: ha ha :-) | 18:36 |
| voidspace | :-) | 18:36 |
| voidspace | rogpeppe: I did wonder about that assignment | 18:37 |
| natefinch | jcastro: yeah | 18:37 |
| voidspace | rogpeppe: but I saw the function returned something and I followed the append pattern | 18:37 |
| rogpeppe | voidspace: ah yes | 18:37 |
| voidspace | but I wondered how it could still be threadsafe :-) | 18:37 |
| rogpeppe | voidspace: append is definitely not atomic | 18:37 |
| voidspace | right | 18:37 |
| voidspace | this must be atomic though | 18:37 |
| voidspace | it says so :-) | 18:37 |
| voidspace | rogpeppe: anyway, fixing and then I'll approve the branch | 18:37 |
| rogpeppe | voidspace: the documentation is quite clear BTW (see the start of the sync/atomic package) | 18:38 |
| voidspace | rogpeppe: I'm a bloke | 18:38 |
| voidspace | I don't read the instructions unless I *really* need to ;-) | 18:38 |
| rogpeppe | voidspace: luckily it's blokish documentation | 18:39 |
| voidspace | hehe | 18:39 |
| voidspace | maybe not ideal for the future diversity of the programming pool though | 18:39 |
| natefinch | jcastro: I made a bug for the add-machine documentation error | 18:39 |
| * Makyo is back (gone 00:07:43) | 18:40 | |
| jcastro | natefinch, I filed one for KVM doc in general | 18:41 |
| jcastro | and mentioned your recommendation | 18:41 |
| natefinch | jcastro: good, someone will get a two-fer when they make the doc fixes then :) | 18:43 |
| * rogpeppe has to finish now | 18:47 | |
| rogpeppe | still not succeeded in finding out what's going on with these mongo servers. currently suspecting a bug in mgo, but we will see. | 18:47 |
| rogpeppe | g'night all | 18:47 |
| ev | is it possible to tell juju about an apt proxy? Cloud init lets you, but it doesn't seem possible to pass that through. | 18:47 |
| ev | hm, probably should've used #juju for that. Soz. Heading there. | 18:48 |
| jcastro | yes, you can define one in environments.yaml | 18:48 |
| jcastro | let me see if I can find it | 18:48 |
| jcastro | "If the machine you are bootstrapping on uses the apt proxy, we | 18:49 |
| jcastro | magically sniff those settings and pass them to the environment via | 18:49 |
| jcastro | cloud init." | 18:49 |
| bodie_ | can someone help me break down what's going on here? http://paste.ubuntu.com/7086357/ | 19:00 |
| bodie_ | (could this be caused by running my own instance of mongo?) | 19:01 |
| natefinch | bodie_: you running mongo shouldn't affect it. The test takes that into account and used custom directories and ports. However, it is a pretty flaky test. some people have had luck cleaning out their /tmp directory and retrying, though I don't know if there's actual cause and effect there | 19:02 |
| * bodie_ sets up cargo altar | 19:02 | |
| bodie_ | hmm, looks like that might have an effect actually | 19:03 |
| bodie_ | removed directory: ‘/tmp/test-mgo959273350’ ... | 19:03 |
| natefinch | bodie_: that may be more of a symptom than a cause, but cleaning it up is a good thing | 19:03 |
| bodie_ | hrm | 19:05 |
| bodie_ | [LOG] 0:00.026 INFO juju mongod: error command line: unknown option sslOnNormalPorts | 19:10 |
| bodie_ | normal? | 19:10 |
| natefinch | bodie_: ahh, no. That means you're not using a version of mongo that supports SSL | 19:11 |
| bodie_ | maybe that means I don't have ssl enabled mongo? but I thought it uses its own mongo | 19:11 |
| bodie_ | well that's annoying | 19:11 |
| natefinch | bodie_: only if you have the special juju mongo installed | 19:11 |
| natefinch | bodie_: I think if you install juju-local from the ppa, it installs the correct mongo | 19:12 |
| bodie_ | I see | 19:12 |
| bodie_ | d'you know if there's a way to retrieve that mongo somehow? | 19:12 |
| bodie_ | I was just going to build from source... | 19:12 |
| natefinch | bodie_: building from source also works, that's what I did | 19:13 |
| natefinch | bodie_: http://www.mongodb.org/about/tutorial/build-mongodb-on-linux/ this link is mostly right... there were some minor inconsistencies and unclear things, and I swear I wrote them up somewhere, but now I can't find them | 19:18 |
| bodie_ | seems to be working ok for me :) we'll see if this build chokes | 19:18 |
| natefinch | cool | 19:21 |
| voidspace | EOD folks | 19:46 |
| voidspace | g'night | 19:46 |
| bodie_ | nite | 19:46 |
| bodie_ | so let's say I push to my new remote branch and my friend wants to check out my commit | 19:48 |
| bodie_ | using bazaar .... how would I figure that out | 19:49 |
| bodie_ | sorry for the n00b questions here | 19:49 |
| hazmat | fwereade, so the other possibility is that your working against an assumption that the charms are doing correct things, when perhaps they are not | 19:49 |
| natefinch | bodie_: bzr branch <your branch> <local_dir> | 19:50 |
| bodie_ | right, let's say I push that to the remote | 19:50 |
| bodie_ | can I have my buddy check out my branch? | 19:51 |
| natefinch | bodie_: yeah, anyone can check out any branch, they just won't be able to push back up to your branch | 19:51 |
| bodie_ | nice! | 19:51 |
| bodie_ | do you know if there's a way to create a shared branch? | 19:51 |
| natefinch | bodie_: the joys of a distributed version control system | 19:52 |
| bodie_ | heh... yes, that's what I'm trying to get at | 19:52 |
| bodie_ | oh, so you have access to all the branches by default once they're pushed | 19:52 |
| bodie_ | all right, I think I get that | 19:52 |
| natefinch | bodie_: probably you can make one, but there's rarely a reason to, and I don't know how (I'm actually pretty new to bazaar myself) | 19:52 |
| bodie_ | ah, well all extra lift is appreciated :) | 19:53 |
| natefinch | man I hate forgetting to use --upload-tools. I wish there was a way to like permanently turn that on | 20:11 |
| wwitzel3 | natefinch: function juju-bootstrap() { juju bootstrap "$@" --upload-tools ;} | 20:14 |
| thumper | haha | 20:14 |
| wwitzel3 | natefinch: also ping on that review I'd like to be done with bug #1289316 so we can actually pair tomorrow (I know you're lookin forward to me slowing you down). | 20:16 |
| _mup_ | Bug #1289316: lxc not installed from ubuntu-cloud.archive on precise <lxc> <maas> <precise> <regression> <juju-core:In Progress by wwitzel3> <https://launchpad.net/bugs/1289316> | 20:16 |
| natefinch | wwitzel3: yeah, working on it. I'll see if I can finish it up. Just struggling with my own demons here. | 20:16 |
| wwitzel3 | natefinch: I can be a rubber duck if you need | 20:18 |
| natefinch | wwitzel3: thanks, but it's really more of a matter of not doing stupid stuff like forgetting --upload-tools :) | 20:18 |
| wwitzel3 | natefinch: ahh well I already helped with that one ;D | 20:20 |
| natefinch | wwitzel3: haha yeah | 20:20 |
| natefinch | wwitzel3: sorry, I don't mean to be a sourpuss :) | 20:24 |
| wwitzel3 | natefinch: np, you're good | 20:30 |
| natefinch | EOD for me | 21:00 |
| wwitzel3 | natefinch: later | 21:01 |
| natefinch | wwitzel3: see you later. We'll pair tomorrow. Maybe you'll see what I'm missing ;) | 21:01 |
| bodie_ | still struggling to hurdle these build errors | 21:10 |
| bodie_ | it's the azure provider | 21:10 |
| bodie_ | is there a revision where it's not broken, or something? or can I lend a hand to get it working? | 21:10 |
| bodie_ | http://paste.ubuntu.com/7086950/ | 21:11 |
| thumper | bodie_: possible that you don't have up to date dependencies | 21:11 |
| bodie_ | i'm on r2416 | 21:11 |
| bodie_ | hm | 21:11 |
| * thumper now looks at the actual error | 21:11 | |
| thumper | bodie_: possible your gwacl is either too old or too new :-) | 21:12 |
| thumper | there is a file 'dependencies.tsv' that lists the deps | 21:12 |
| thumper | wallyworld_: got a minute? | 21:12 |
| thumper | wallyworld_: hangout? | 21:12 |
| wallyworld_ | ok | 21:12 |
| bodie_ | I see -- do you know if there are plans to integrate the DO provider into the source tree? (when you're finished there) | 21:13 |
| bodie_ | (or if anyone else has input) | 21:13 |
| wallyworld_ | thumper: you got a url for me? | 21:14 |
| thumper | bodie_: possible, but not a priority right now | 21:14 |
| thumper | wallyworld_: just getting it | 21:15 |
| * wallyworld_ taps fingers impatiently | 21:15 | |
| thumper | wallyworld_: geez, sorry... https://plus.google.com/hangouts/_/76cpid01ju5bni12d56tdh441c?hl=en | 21:15 |
| * wallyworld_ was trolling | 21:15 | |
| waigani | thumper: checkers branch is already merged | 22:34 |
| thumper | waigani: but you didn't remove juju-core/testing/checkers | 22:34 |
| waigani | ah | 22:35 |
| thumper | o/ DarrenS | 22:39 |
| waigani | thumper: should all other instances of "launchpad.net/juju-core/testing/testbase" be replaced with "github.com/juju/testing" - instances not using LoggingSuite that is | 22:39 |
| thumper | oops | 22:39 |
| thumper | tab fail | 22:39 |
| thumper | o/ davecheney | 22:39 |
| thumper | waigani: no | 22:39 |
| thumper | not yet | 22:39 |
| thumper | there are some things that need changing | 22:39 |
| thumper | it isn't that trivial | 22:39 |
| waigani | thumper: hangout? | 22:39 |
| thumper | um... if we can keep it quick | 22:40 |
| waigani | yep | 22:40 |
| thumper | https://plus.google.com/hangouts/_/76cpjj9kf8th4q7frgnv40r7mc?hl=en | 22:40 |
| wallyworld | fwereade: thanks for looking at my branch. the embedded interface in httpHandler is because httpHandler itself is an embedded struct and the containing struct provides the interface implementation. and Go doesn't have abstract methods :-( I added a comment | 22:49 |
| fwereade | wallyworld, LGTM | 22:56 |
| wallyworld | fwereade: awesome, thanks | 22:56 |
| fwereade | waigani, I LGTMed https://code.launchpad.net/~waigani/juju-core/change-ConfigValidator-cfg-obj-to-type-string/+merge/208983 a week ago, you might not have noticed? | 22:58 |
| waigani | fwereade: yep, I saw that thanks. Since then I've dug a whole for myself with this monster of a branch: https://codereview.appspot.com/70190050/ | 23:00 |
| waigani | fwereade: I'm learning the hard way why is important to have small branches. | 23:01 |
| fwereade | waigani, yeah, it's one of those things that only really becomes clear the hard way | 23:02 |
| waigani | heh | 23:02 |
| waigani | *hole | 23:02 |
| wallyworld | thumper: are you able to look at bug 1291207 (critical for 1.17.5) so i can start on the ppc work? | 23:21 |
| _mup_ | Bug #1291207: juju-run symlink is broken after upgrade-juju <run> <upgrade-juju> <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1291207> | 23:21 |
| davecheney | gz: u there ? | 23:32 |
| davecheney | mgz_: u there ? | 23:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!