| axw | wallyworld_: I think the bot might need a poke again? waigani 's branch looks stuck (https://code.launchpad.net/~waigani/juju-core/expand-config-variable-names/+merge/204412) | 01:59 |
|---|---|---|
| wallyworld_ | ok | 01:59 |
| axw | and my MP is attached to the bug here: https://bugs.launchpad.net/gwacl/+bug/1276019 | 02:00 |
| _mup_ | Bug #1276019: 307s are not followed other than for GET/HEAD, and headers are dropped from those <Go Windows Azure Client Library:In Progress by axwalk> <https://launchpad.net/bugs/1276019> | 02:00 |
| wallyworld_ | axw: bot seems ok actually | 02:00 |
| axw | hm ok | 02:00 |
| wallyworld_ | it's running a test now | 02:01 |
| wallyworld_ | axw: ah error | 02:01 |
| wallyworld_ | erging https://code.launchpad.net/~waigani/juju-core/expand-config-variable-names into https://code.launchpad.net/~go-bot/juju-core/trunk would be pointless | 02:01 |
| axw | ah. 6 hours just seemed like a long time :) | 02:01 |
| axw | oh | 02:01 |
| wallyworld_ | so there's a problem with the branch | 02:01 |
| wallyworld_ | it could be that trunk already has the changes | 02:02 |
| wallyworld_ | yes | 02:02 |
| wallyworld_ | it does | 02:02 |
| axw | okey dokey | 02:02 |
| wallyworld_ | so i'd say another merge accidentally has these changes in it | 02:03 |
| wallyworld_ | i set the mp to merged | 02:03 |
| axw | wallyworld_: FYI, I have Thursday/Friday off | 02:26 |
| wallyworld_ | lucky bugger | 02:26 |
| wallyworld_ | enjoy | 02:26 |
| axw | ta :) | 02:27 |
| axw | wallyworld_: I have pushed another change to the gwacl MP. Tested live - works better now. | 04:48 |
| wallyworld_ | ok, looking | 04:48 |
| wallyworld_ | axw: to be consistent and simplify the code, should we always just check the response code and avoid needed to return a httpredirect error for some calls and not others | 04:50 |
| axw | wallyworld_: the error must be returned to prevent net/http from following redirects at all | 04:51 |
| wallyworld_ | ah right | 04:51 |
| wallyworld_ | in that case, looks good | 04:51 |
| axw | cheers | 04:51 |
| hazmat | axw, out of curiosity, what do you think about add-machine ssh: supporting instance id on the cli? | 06:41 |
| axw | hazmat: yeah, could be useful for manually provisioning into existing environments, e.g. on ec2 | 06:42 |
| axw | so the instance becomes managed by juju | 06:42 |
| hazmat | i'm writing a cli plugin, and could avoid the use of the api entirely, if i could just set the instance id i could just use the cli. | 06:42 |
| hazmat | its mostly so i can correlate directly back to the underlying provider instance easily without doing ip addr matching. | 06:43 |
| axw | right | 06:43 |
| axw | I think it would have to be encoded into the address somehow | 06:43 |
| axw | to avoid further special casing of add-machine | 06:43 |
| hazmat | axw, ssh:user@ipaddress:instance_id ? | 06:44 |
| axw | we might want : for non-standard ssh ports later. I'd say something like / or = | 06:44 |
| axw | but anyway, yeah it could work | 06:45 |
| hazmat | sounds good, i'll file a bug | 06:47 |
| davecheney | axw: i was thinking about what could be done to make the gccgo detection work | 08:12 |
| davecheney | it would be abomonation, but could proabably be done | 08:12 |
| axw | davecheney: yup. I was thinking the same thing, i.e. a known caller name | 08:12 |
| axw | I wouldn't bother changing it now though, maybe if it needs to be changed again... | 08:13 |
| davecheney | axw: i think we're goig to be flapping between 4.8 and 4.9 for some time | 08:13 |
| davecheney | it might be worth the effort to gold plate it | 08:14 |
| axw | heh ok :) | 08:14 |
| davecheney | axw: it might also be possible to cheat | 08:15 |
| davecheney | gccgo 4.8 implements go 1.1 | 08:15 |
| davecheney | maybe I can use a +build tag | 08:15 |
| axw | 1.1? :( | 08:15 |
| axw | I thought we had moved to 1.2 now | 08:16 |
| davecheney | gccgo 4.8 implements the 1.1 spec | 08:16 |
| rogpeppe | davecheney, axw: mornin' | 08:17 |
| axw | morning rogpeppe | 08:18 |
| dimitern | morning all | 08:26 |
| dimitern | rogpeppe, i have some questions re goamz, and since gustavo is not around, do you have some time? | 08:26 |
| rogpeppe | dimitern: sure | 08:26 |
| dimitern | rogpeppe, so, i've tried (hard) yesterday to construct a sophisticated multi-part test that runs both on the test double and live | 08:27 |
| dimitern | rogpeppe, but i've run into issues like eventual consistency and such (i.e. i'd really like to have something similar to Long/ShortAttempt in goamz) | 08:28 |
| rogpeppe | dimitern: i think goamz already has the attempt stuff in | 08:28 |
| dimitern | rogpeppe, am I to take from this such tests are not needed inside goamz itself, but just simpler ones that focus on response parsing is ok etc. | 08:29 |
| rogpeppe | dimitern: yeah, aws.AttemptStrategy | 08:29 |
| dimitern | rogpeppe, ah, I've missed that | 08:29 |
| dimitern | rogpeppe, also i found the ec2test package a bit inflexible | 08:29 |
| dimitern | rogpeppe, i.e. you cannot easily setup the same case and make sure it'll run the same on both local and live servers | 08:30 |
| rogpeppe | dimitern: yeah, it was as simple as i could come up with | 08:30 |
| rogpeppe | dimitern: i'm not sure what you mean by that though | 08:31 |
| dimitern | rogpeppe, like state changes over time in instances / other entities | 08:31 |
| rogpeppe | dimitern: there are quite a few existing tests that work both live and against ec2test | 08:31 |
| dimitern | rogpeppe, there's an SetInitialInstanceState | 08:31 |
| dimitern | rogpeppe, yeah, and I've done mine similarly, but for more complex cases it's much too difficult | 08:31 |
| rogpeppe | dimitern: what would you like to be able to do? | 08:32 |
| dimitern | rogpeppe, like "i need to test network interface ops", but for that i need: 1) a vpc, 2) a subnet, 3) a *running* instance in that subnet, 4) a security group for that vpc, 5) the net interface itself | 08:33 |
| dimitern | rogpeppe, i.e. the set up is heavy, slow when run live and not very reliable | 08:34 |
| rogpeppe | dimitern: i think that it's going to be hard to have ec2test actually run a live instance | 08:34 |
| dimitern | rogpeppe, apart from errors due to my assumptions, sometimes i get errors like "503 unavailable" or some random error | 08:34 |
| rogpeppe | dimitern: and the heavy & slow setup applies to ec2 live tests, not ec2test, right? | 08:35 |
| dimitern | rogpeppe, so it's best to separate the local and live test cases for more complex scenarios | 08:35 |
| rogpeppe | dimitern: and the reliability problems too, i'd guess | 08:35 |
| dimitern | rogpeppe, 2x yep | 08:35 |
| rogpeppe | dimitern: why do you need a running instance? | 08:35 |
| dimitern | rogpeppe, because you can't attach a NIC on a instance that's not in running state | 08:35 |
| dimitern | rogpeppe, unless you've done it at runinstances time, but that's another test | 08:36 |
| rogpeppe | dimitern: ok, so you don't actually need it to be running something, just for it to report the state as running | 08:36 |
| dimitern | rogpeppe, yes | 08:37 |
| rogpeppe | dimitern: i'm not sure that particular case matters too much to test. is it that important to check all error states? | 08:38 |
| dimitern | rogpeppe, take a look at what i've came up with after several hours of trial-and-frustration yesterday: http://paste.ubuntu.com/6877862/ | 08:38 |
| rogpeppe | dimitern: BTW it's good to at least have the live tests, because then you get to know just how it's likely to fail for real | 08:39 |
| dimitern | it's not ready yet, i'll split it up, etc. but it works 60% of the time up to the last Check() which fails with "NIC cannot be deleted because it's in use" (but got detached ok) | 08:39 |
| rogpeppe | dimitern: presumably you'll need to do a retry loop around the DeleteNetworkInterface call | 08:40 |
| rogpeppe | dimitern: i'm still not quite seeing how the ec2test package isn't flexible enough for your needs here | 08:41 |
| rogpeppe | dimitern: ISTM that the real difficulty is writing reliable live tests | 08:41 |
| dimitern | rogpeppe, yes, but i was too tired yesterday already - i'll also replace my jury rigged loop with attemptstrategy if possible | 08:41 |
| dimitern | rogpeppe, isn't because it's not simulating the "eventual consistency" of certain features | 08:42 |
| dimitern | rogpeppe, like "make the instance state change slowly" or "do not delete X immediately, but say you did, and report it in use for some time after" | 08:42 |
| rogpeppe | dimitern: it's true, it doesn't, because it's hard to see how to get it right. but surely your tests will work ok if ec2test is always consistent? | 08:43 |
| davecheney | rogpeppe: morning -- sorry, missed your thinggy | 08:43 |
| rogpeppe | davecheney: hiya | 08:43 |
| dimitern | rogpeppe, yes, I started with a far easier test that worked on ec2test like charm | 08:43 |
| dimitern | rogpeppe, the problem was to achieve the same live using the same steps, which turned into this | 08:44 |
| rogpeppe | dimitern: i don't see why ec2test is making things harder here | 08:44 |
| rogpeppe | s/why/how/ | 08:44 |
| rogpeppe | dimitern: BTW, rather than polling by calling Instances repeatedly, might it not be better to just call CreateNetworkInterface repeatedly until it doesn't return the expected error? | 08:47 |
| rogpeppe | dimitern: then you won't need to worry about the fact that ec2test instances don't transition to running state | 08:47 |
| dimitern | rogpeppe, that's a good point, thanks | 08:52 |
| dimitern | rogpeppe, and then there are 2 more things i've been wondering about | 08:52 |
| dimitern | rogpeppe, 1) how detailed should be the tests checking for errors (i.e. how good the ec2test package should simulate all cases) | 08:53 |
| rogpeppe | dimitern: it's not that important | 08:54 |
| dimitern | rogpeppe, and 2) right now goamz uses a fairly outdated api version - 2011-12-15, but some features we need are in later versions | 08:54 |
| dimitern | rogpeppe, should we support mixed versions? | 08:54 |
| rogpeppe | dimitern: ec2test is a test double for the ec2 provider - it doesn't need to simulate all errors; getting the happy path right is what we've done so far | 08:55 |
| rogpeppe | dimitern: i think we should use the earliest version that supports the features we need | 08:55 |
| rogpeppe | dimitern: or... perhaps just update the whole thing to use the latest version | 08:56 |
| rogpeppe | dimitern: there might not actually be too much in the way of changes | 08:56 |
| dimitern | rogpeppe, upgrading everything is less than trivial | 08:57 |
| dimitern | rogpeppe, but perhaps worth it | 08:57 |
| rogpeppe | dimitern: yeah, i'm not entirely sure. | 08:58 |
| rogpeppe | dimitern: the version is per-request though, right? | 08:58 |
| dimitern | rogpeppe, right | 08:59 |
| dimitern | rogpeppe, so far the least intrusive approach would be to change the version only for the new calls and only for the old ones if it's unavoidable | 09:00 |
| rogpeppe | dimitern: yeah, i think that's a good approach to start with | 09:00 |
| dimitern | rogpeppe, how about supporting different filters in ec2test? | 09:02 |
| rogpeppe | dimitern: is there a problem with just adding the new filters? | 09:03 |
| dimitern | rogpeppe, some are quite broad, like 25 cases | 09:03 |
| dimitern | rogpeppe, so ec2test should support all filters for the new entities | 09:03 |
| rogpeppe | dimitern: ec2test does not have to support everything, but it should support the things that are being used | 09:04 |
| dimitern | rogpeppe, by whom? | 09:04 |
| rogpeppe | dimitern: by your live test and by provider/ec2 | 09:04 |
| dimitern | rogpeppe, yep, but on one hand i'm not sure what we'll need in the provider, on the other - it's a generic library after all and it has other users that might benefit from fuller implementation | 09:05 |
| rogpeppe | dimitern: i'd err on the "do less" side to start with | 09:06 |
| rogpeppe | dimitern: that's been my approach since the start - the amazon API is much larger than we need to entirely support | 09:06 |
| dimitern | rogpeppe, ok then, i'll try to be minimalistic in the implementation :) | 09:07 |
| rogpeppe | dimitern: so, pending actual code in the provider that uses the stuff, i'd just add the functionality in ec2test that's needed by the live tests, so that they can run on ec2test as well as live | 09:07 |
| rogpeppe | dimitern: that's always a good thing in my book :-) | 09:07 |
| dimitern | rogpeppe, :) ok, thanks for the suggestions | 09:08 |
| rogpeppe | dimitern: np | 09:08 |
| dimitern | rogpeppe, can you take a look at this please? https://codereview.appspot.com/49930045/ re what we just discussed | 09:09 |
| dimitern | (i.e. could it be simplified) | 09:10 |
| rogpeppe | dimitern: looking | 09:10 |
| === bradm1 is now known as bradm | ||
| mgz | standup all? | 10:46 |
| natefinch | dimitern, rogpeppe: standup? | 10:48 |
| mgz | totally forgot to mention in standup, landing bot will be down shortly, I'll give you guys a heads up when it's online again | 11:18 |
| jam | mgz: poke, i'd like to tweak some of the bot stuff, but I'd appreciate your help | 11:40 |
| mgz | jam: sure, remember it's all going down in ~15 mins | 11:45 |
| jam | mgz: sorry about the delay. I'd like to see us add "go test -test.timeout 2m" to the test suite, so that instead of getting the 10m test-took-too-long, we'll get a panic if any individual test takes more than 2min | 12:14 |
| jam | we shouldn't take longer than that for a test we're writing anyway | 12:15 |
| jam | and it might help us debug WTF for the provisioner | 12:15 |
| mgz | jam: that sounds reasonable | 12:17 |
| jam | mgz: good. I just saw the "maintenance starting now" which reminded me I wanted to poke you about the bot for when it comes back up | 12:18 |
| jam | we need to change that stuff in the juju conf, otherwise the bot will overwrite it all when it comes up | 12:18 |
| mgz | we can just set the tarmac-conf value when we have the state server back, right? | 12:25 |
| jam | mgz: well, and deal with any fallout of stuff that didn't actually get put into conf properly. | 12:34 |
| jam | but we have to do that anyway | 12:34 |
| === _mup__ is now known as _mup_ | ||
| === gary_poster|away is now known as gary_poster | ||
| dimitern | mgz, hey, i've just updated all the CLs and proposed the NIC one: 1 https://codereview.appspot.com/49930045/ 2 https://codereview.appspot.com/54690048/ 3 https://codereview.appspot.com/54570048/ | 13:41 |
| dimitern | rogpeppe, ^^ if you can take a look as well would be nice | 14:03 |
| rogpeppe | dimitern: will do | 14:03 |
| mgz | dimitern: thanks | 14:05 |
| rogpeppe | dimitern: you've got one review | 14:29 |
| dimitern | rogpeppe, cheers! | 14:30 |
| dimitern | rogpeppe, the "you" phrasing is copied from aws docs :) | 14:31 |
| rogpeppe | dimitern: yeah, but it's not idiomatic in the goamz docs (no other occurrences of "You" AFAICS) | 14:31 |
| dimitern | rogpeppe, sure, thanks for spotting | 14:36 |
| rogpeppe | dimitern: you've got another review | 14:47 |
| dimitern | rogpeppe, ta | 14:48 |
| rogpeppe | dimitern: all reviewed :-) | 15:17 |
| dimitern | rogpeppe, tyvm! | 15:19 |
| rogpeppe | dimitern: thanks for all that work | 15:19 |
| dimitern | rogpeppe, there's even more coming :) | 15:19 |
| rogpeppe | dimitern: presumably the live tests pass? | 15:19 |
| dimitern | rogpeppe, but i'm fast now, it should be easier | 15:20 |
| dimitern | rogpeppe, yep, ran them several times in a row | 15:20 |
| rogpeppe | dimitern: cool | 15:20 |
| mgz | what's a safe way to stop and restart jujud on a state server? | 15:23 |
| natefinch | mgz: sudo restart juju possibly? | 15:26 |
| mgz | jujud-machine-0 it seems | 15:27 |
| natefinch | rogpeppe: is there a way to compile all regular and test code at the same time, but not run the tests? | 15:29 |
| natefinch | (or if anyone else knows) | 15:29 |
| rogpeppe | natefinch: go test -c | 15:29 |
| rogpeppe | natefinch: except that unfortunately you can't run "go test -c ./..." | 15:29 |
| natefinch | rogpeppe: Tried that, but it does't work across packages, though. I want go test ./... -c | 15:29 |
| natefinch | right | 15:29 |
| rogpeppe | natefinch: i have a script that does that | 15:29 |
| rogpeppe | natefinch: i call it "gotest-c" | 15:29 |
| natefinch | rogpeppe: nice | 15:29 |
| rogpeppe | natefinch: http://paste.ubuntu.com/6879643/ | 15:30 |
| rogpeppe | natefinch: i should probably change it to use bash so other people can use it :-) | 15:30 |
| natefinch | rogpeppe: haha yeah I was thinking that | 15:31 |
| rogpeppe | natefinch: you can get pxargs with go get code.google.com/p/rog-go/cmd/pxargs | 15:31 |
| rogpeppe | natefinch: (it's similar to xargs except runs commands in parallel) | 15:31 |
| rogpeppe | natefinch: http://paste.ubuntu.com/6879677/ | 15:35 |
| mgz | hm, so the real issue is I can't get the juju-db service to stick, comes up with no error, nothing in upstart log, but no mongodb process survives | 15:39 |
| mgz | probably just the out of disk thing, will restart and watch syslog more closely | 15:40 |
| jam | mgz: this is the tarmac machine-0? (vs the actual tarmac machine-1 that runs the bot?) | 15:42 |
| mgz | yeah, playing with machine-0 | 15:42 |
| mgz | looks in better state at attempt #2 | 15:42 |
| mgz | hm, I say that, it's spamming machine-0.log still | 15:43 |
| mgz | well, that sucked | 15:59 |
| mgz | had to manually fix the provider-state file, and clean up spammed out logs for disk space | 15:59 |
| mgz | logging ever 2s a state connection can't be made is pretty disk filling too | 16:01 |
| rogpeppe | lunch | 16:05 |
| jam | have a good night, we're heading off to dinner | 16:12 |
| rogpeppe | dimitern: does this look reasonable to you? http://paste.ubuntu.com/6880125/ | 16:55 |
| rogpeppe | dimitern: i'm trying to check if a field is either false or not present | 16:56 |
| rogpeppe | dimitern: (the hasvote clause) | 16:56 |
| rogpeppe | dimitern: but it doesn't appear to be working | 16:56 |
| dimitern | rogpeppe, shouldn't it be more like {"$or", []D{{{"hasvote", D{{"$ne", true}}}}}} ? | 16:59 |
| rogpeppe | dimitern: ah, that's a much better idea | 17:00 |
| rogpeppe | dimitern: (and no need for the $or then) | 17:00 |
| rogpeppe | dimitern: solved, thanks! | 17:01 |
| * rogpeppe feels a bit stupid :-) | 17:01 | |
| dimitern | rogpeppe, ;) np | 17:03 |
| natefinch | Man that mgo code kills me | 17:06 |
| rogpeppe | natefinch: it's the subtle distinctions between maps and arrays that i always forget | 17:13 |
| rogpeppe | dimitern, natefinch: fairly trivial review? https://codereview.appspot.com/50590045/ | 17:16 |
| rogpeppe | dimitern, natefinch: and an even more trivial one: https://codereview.appspot.com/54690051 | 17:26 |
| dimitern | rogpeppe, looking at both in order | 17:31 |
| rogpeppe | dimitern: thanks! | 17:31 |
| natefinch | rogpeppe: looking at both in reverse order | 17:33 |
| dimitern | rogpeppe, both reviewed | 17:38 |
| rogpeppe | dimitern: thanks a lot | 17:39 |
| rogpeppe | dimitern, natefinch: and one last one, also trivial: https://codereview.appspot.com/59740049 | 17:41 |
| dimitern | rogpeppe, LGTM | 17:43 |
| rogpeppe | dimitern: | 17:43 |
| rogpeppe | dimitern: ta! | 17:43 |
| rogpeppe | oh dear, the gobot seems to be broken | 18:05 |
| rogpeppe | flag provided but not defined: -test.timeout | 18:05 |
| rogpeppe | mgz: do you know why that was changed? | 18:06 |
| mgz | jam asked earlier | 18:13 |
| mgz | I'll get back to fixing it if I manage to recover juju, which is pretty severly borked | 18:13 |
| rogpeppe | mgz: ok, thanks | 18:22 |
| rogpeppe | i'm done for the day. g'night all. | 18:22 |
| mgz | night! | 18:22 |
| natefinch | rogpeppe: g'night | 18:22 |
| mgz | okay, I might have un-stuck it | 18:24 |
| mgz | but we're kind of in a bad spot | 18:24 |
| mgz | the juju version for the landing bot is still 1.11.0 and because of all the tools and config changes, it actually not upgradable | 18:24 |
| mgz | or at least, I'd need to refer back to each old version to find the correct tools config to pass both client and remote side lookup of tools, then walk it up the versions | 18:25 |
| mgz | which... I don't want to do | 18:25 |
| natefinch | mgz: can we not just kill it and redeploy with a new juju? | 18:38 |
| mgz | natefinch: I think that would be the sanest option, but the tarmac charm needs work first | 18:41 |
| natefinch | mgz: so is this because we didn't keep up with upgrades, or what? What do we expect users to do in this situation? | 18:42 |
| mgz | roll over and die I think... | 18:43 |
| natefinch | mgz: that seems to not be the most user friendly decision... :/ | 18:43 |
| mgz | seriously though, we should probably make sure any one who runs juju for semi-production stuff does an upgrade at each major version | 18:44 |
| mgz | though we should be less churny than we were last year | 18:44 |
| mgz | going through three config settings and a bunch of different layouts for tools stuff was pretty nuts | 18:45 |
| natefinch | mgz: we really just need to review our upgrade story.... there's no reason you shouldn't be able to upgrade directly from 1.11 to 1.17 (or whatever). You just run the code that does 1.11->1.12, then run the code that does 1.12->1.13, etc (or whatever... I know we do that wacky even odd thing) | 18:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!