| thumper | grr | 00:07 |
|---|---|---|
| thumper | davecheney: I'm getting grumpy at go right now... | 00:11 |
| thumper | http://paste.ubuntu.com/5775663/ | 00:11 |
| thumper | http://paste.ubuntu.com/5775665/ | 00:12 |
| thumper | davecheney: any idea what I'm doing wrong? | 00:12 |
| thumper | http://paste.ubuntu.com/5775667/ | 00:12 |
| thumper | file.go:10:2: import "launchpad.net/testing/checkers": cannot find package | 00:13 |
| thumper | hmm... | 00:13 |
| thumper | ah... | 00:14 |
| thumper | forgot the juju-core bit | 00:14 |
| thumper | works now | 00:15 |
| thumper | nm | 00:15 |
| davecheney | thumper: glad you solved it | 00:21 |
| bigjools | how much attention is getting paid to locking critical sections in providers for non re-entrant code? | 01:21 |
| thumper | bigjools: lots | 01:34 |
| thumper | bigjools: AFAIK, providers should be reentrant | 01:34 |
| bigjools | they can try to be :) | 01:34 |
| thumper | can accessible from multiple go routines | 01:34 |
| thumper | bigjools: right, just not dying is a good start | 01:35 |
| bigjools | one of my esteemed colleagues was whinging about something | 01:35 |
| bigjools | I figured it can't be that bad | 01:35 |
| bigjools | thumper: oh the actual whinge was that concurrency/locking was not tested | 01:36 |
| bigjools | is that right? | 01:36 |
| thumper | probably | 01:36 |
| bigjools | ok | 01:37 |
| thumper | wallyworld: can I get you to look at https://codereview.appspot.com/10344044/ ? | 01:47 |
| thumper | wallyworld: also, I have made an IsTrue checker | 01:47 |
| wallyworld | ok | 01:54 |
| wallyworld | +100000 for the IsTrue checker | 01:59 |
| thumper | wallyworld: it will land with my lxc-container branch | 02:18 |
| wallyworld | kk | 02:20 |
| thumper | wallyworld: so... fake vs mock | 03:10 |
| wallyworld | yeees? | 03:10 |
| thumper | actually, those instances are neither fakes nor mocks | 03:11 |
| thumper | in the traditional sense | 03:11 |
| * wallyworld doesn't really care about the name | 03:12 | |
| wallyworld | land it i say | 03:12 |
| thumper | so, tests say... Mocks have internal assertions | 03:12 |
| thumper | fakes fake it | 03:12 |
| wallyworld | yeah | 03:12 |
| thumper | stubs are always dumb and the same | 03:12 |
| thumper | so kinda fakes | 03:12 |
| * thumper lands it | 03:13 | |
| wallyworld | \o/ | 03:13 |
| * thumper proposes the lxc-container branch | 03:17 | |
| hallyn | thumper: well, that figures. today raring is bootstrapping fine. ! Thanks anyway :) | 03:19 |
| thumper | heh | 03:33 |
| thumper | wallyworld: Rietveld: https://codereview.appspot.com/10370044 | 03:41 |
| * wallyworld looks | 03:42 | |
| wallyworld | thumper: i gotta take the dog to the vet, i'll finish the review when i get back soon | 03:46 |
| thumper | wallyworld: kk | 03:47 |
| thumper | wallyworld: todo with the claw? | 03:47 |
| wallyworld | thumper: yes, it is almost better | 04:25 |
| === tasdomas_afk is now known as tasdomas | ||
| * thumper sighs | 04:49 | |
| thumper | ... | 04:49 |
| wallyworld | thumper: for lxcFactory, did you consider making the containerfactory embedded? i can't see a need for the lxc attribute, just confuses things | 05:07 |
| thumper | no, didn't consider that | 05:07 |
| thumper | except I use separation at time | 05:07 |
| thumper | particularly in the tests | 05:07 |
| thumper | but perhaps it doesn't matter? | 05:08 |
| * thumper is EODing to make dinner | 05:08 | |
| thumper | lxc-broker review coming too | 05:08 |
| wallyworld | thumper: ok, i'll make the comment in the review | 05:08 |
| jam | thumper, wallyworld: it looks like the stability stuff has been handled on go-bot. Have either of you had a patch rejected? (I don't see anything in the logs) | 06:26 |
| wallyworld | jam: nope, so far so good \o/ | 06:27 |
| rvba | Hi fwereade… I'm not sure I understand your comments on this branch… should I mark the MP on launchpad approved and get this landed or is there something wrong somewhere? | 06:59 |
| rvba | s/this branch/my branch/ | 06:59 |
| fwereade | rvba, it looks like there's a storage-list-files branch that's the same as az-config-2 | 07:00 |
| fwereade | rvba, please get another review from someone on whichever you wish, then land it | 07:00 |
| rvba | fwereade: that's probably the result of me messing with lbox. | 07:00 |
| rvba | Oh, I thought one review was enough these days. | 07:01 |
| rvba | But okay. | 07:01 |
| TheMue | morning | 07:09 |
| jam | morning TheMue | 07:10 |
| rvba | Hi guys, could I please get a second review of https://code.launchpad.net/~rvb/juju-core/az-config-items2/+merge/169759 / https://codereview.appspot.com/10340044/ ? | 07:10 |
| TheMue | rvba: *click* | 07:11 |
| TheMue | jam: hiya | 07:11 |
| rvba | TheMue: thanks! | 07:11 |
| fwereade | rvba, if you get a "LGTM trivial", that's good enough, but for everything else wait for 2xLGTM please | 07:20 |
| rvba | All right. | 07:21 |
| === tasdomas is now known as tasdomas_afk | ||
| fwereade | so, guys, I'll be off for most of the morning because (1) I have an appointment at 10 and (2) I was up way past my bedtime last night doing https://codereview.appspot.com/10251047 | 07:22 |
| TheMue | rvba: another lgtm | 07:23 |
| rvba | TheMue: ta | 07:23 |
| TheMue | fwereade: oh, will take a look. and you take care for yourself and recover | 07:24 |
| fwereade | fwiw I now have 6 branches up on https://code.launchpad.net/juju-core/+activereviews and, while I could probably just land state-testable-transaction as is, even that one would apreciate a second pair of eyes (because it changed a lot since the first lgtms) | 07:24 |
| fwereade | TheMue, thanks | 07:24 |
| fwereade | TheMue, cheers :) | 07:25 |
| TheMue | fwereade: i've got duty today, so i'll walk through your cls | 07:25 |
| fwereade | TheMue, great, ta | 07:25 |
| === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: TheMue | Bugs: 9 Critical, 79 High - https://bugs.launchpad.net/juju-core/ | ||
| rogpeppe1 | mornin' all | 07:42 |
| TheMue | rogpeppe1: morning roger | 07:44 |
| rogpeppe2 | fwereade, TheMue: pretty trivial (but with nice effects!): https://codereview.appspot.com/10375043 | 07:54 |
| TheMue | rogpeppe2: just working on a different one by thumper, but then I'll take yours | 08:10 |
| rogpeppe2 | TheMue: thanks | 08:10 |
| === rogpeppe2 is now known as rogpeppe | ||
| TheMue | rogpeppe: you've got a lgtm | 09:36 |
| rogpeppe | TheMue: thanks | 09:40 |
| rogpeppe | fwereade: TheMue says trivial but I'd like your LGTM just to OK where I've put the tweaks, if you're around. https://codereview.appspot.com/10375043 | 09:41 |
| fwereade | rogpeppe, concur, but maybe call it FastInsecureHash or something, just to be clear | 10:05 |
| rvba | TheMue: thanks for the review, I'll land that branch as it's definitely a trivial change :). | 10:05 |
| rogpeppe | fwereade: ok | 10:05 |
| rogpeppe | fwereade: thanks | 10:05 |
| TheMue | rvba: it is, yes | 10:19 |
| hazmat | g'morning.. getting some odd failures trying out a fresh juju environment on ec2 today. new machines after bootstrap aren't being created | 10:53 |
| hazmat | sound familiar? this is on trunk | 10:53 |
| hazmat | hmmm. go 1.1 issue maybe | 10:54 |
| mgz | what sort of failures? | 10:54 |
| hazmat | mgz, that's the odd part, no failures, just failure to converge on state. i've had a machine pending for 10m, but nothing of note in the logs | 10:55 |
| fwereade | hazmat, there is currently an incompatibility with 1.10/1.11, so unless you --upload-tools it won't work | 10:56 |
| fwereade | hazmat, it's in review now | 10:56 |
| hazmat | ah, ic | 10:56 |
| hazmat | fwereade, thanks | 10:56 |
| hazmat | fwereade, fwiw --upload-tools didn't do the trick, i'll wait for the config incompatibility mp | 11:06 |
| hazmat | oh.. maybe it did | 11:10 |
| * hazmat retries w/ patience | 11:11 | |
| jam | mgz, danilos, wallyworld_: I think my son just hurt his knee, so I have to take him to the ER. I'm going to miss the standup | 11:13 |
| mgz | jam: okay | 11:14 |
| danilos | jam: ack, I hope it's not something serious, good luck | 11:14 |
| hazmat | fwereade, so with --upload-tools, and deploying a service, i end up with a second machine, that tries to loops on a connect to mongodb on localhost, which is correct per its cloudinit data. | 11:25 |
| fwereade | hazmat, hmmmmm, that sounds as though it might be an issue with tim's provisioner stuff | 11:44 |
| fwereade | hazmat, thanks for flagging it, I'll investigate | 11:44 |
| fwereade | rogpeppe, btw, what's the ETA on having agents actually connecting to the API? I have a feeling you were working a branch a little while ago..? | 12:20 |
| FunnyLookinHat | seen Dave Cheney ? | 12:23 |
| fwereade | FunnyLookinHat, bad time of day for him, I think; maybe I can help? | 12:26 |
| FunnyLookinHat | fwereade, Just had some back an forth with him on this bug and didn't want to be updating it / bugging him about it if invalid... I know you guys have lots to do :) https://bugs.launchpad.net/juju-core/+bug/1124561 | 12:26 |
| _mup_ | Bug #1124561: the Content-Length header is missing <Go OpenStack Exchange:Invalid> <juju-core:Invalid> <https://launchpad.net/bugs/1124561> | 12:26 |
| FunnyLookinHat | I had accidentally misread the original bug and so when I applied it to juju-core it didn't really make sense... my mistake. | 12:27 |
| fwereade | FunnyLookinHat, that sounds sane to me for juju-core, but looks like it's worth reopening in goose | 12:29 |
| jtv | Hi team — got time for a review? Got a proposal up here. Sorry to ask — we're in that initial phase for our work where everyone's blocking on everyone's branches. Proposal is https://codereview.appspot.com/10367045/ | 12:29 |
| FunnyLookinHat | fwereade, Ah ok - thanks for the confirmation | 12:30 |
| fwereade | jam, mgz: you guys know goose; it looks to me like that should hopefully be a relatively simple fix that'll unblock FunnyLookinHat, so would one of you please take a quick look at lp:1124561? see comment #5 in particular | 12:31 |
| fwereade | jtv, on it | 12:31 |
| jtv | thanks fwereade! | 12:32 |
| FunnyLookinHat | fwereade, should I create a new bug or just change the status? I'm not familiar with LP etiquette | 12:32 |
| FunnyLookinHat | Ah thx :D | 12:32 |
| rogpeppe | fwereade: currently eating lunch, will get back to you | 12:36 |
| fwereade | rogpeppe, cheers | 12:36 |
| fwereade | FunnyLookinHat, put it back to New I guess? hopefully mgz or jam will take a look shortly and confirm | 12:38 |
| FunnyLookinHat | Ok - thanks | 12:38 |
| fwereade | FunnyLookinHat, if it's simple and an unblocker for you I might be able to pick it up myself if they can't -- and if it hasn't been touched by tomorrow please prod me | 12:39 |
| FunnyLookinHat | fwereade, No worries - I have plenty to do on my end... I've unblocked myself by having my own branch of goose... now I'm working with Rackspace to sort out some object-store issues | 12:40 |
| FunnyLookinHat | Thanks again for your help | 12:40 |
| fwereade | FunnyLookinHat, ah, great | 12:40 |
| jam | fwereade: reading the goose code POST is intentionally a chunked request (it takes an io.Reader to send, not a set of bytes to upload) | 12:44 |
| jam | whether we can change that 'trivially' I don't know. But all of our POSTs are chunked by design. | 12:45 |
| rogpeppe | fwereade: hands are free now :-) | 12:47 |
| fwereade | jam, ahh, hmm, that'd be why the storage interface takes a reader and a length I suppose? | 12:48 |
| fwereade | rogpeppe, cool | 12:48 |
| rogpeppe | fwereade: i'm very much hoping to have some branches (re)proposed by end today/tomorrow. currently sorting out numerous non-flagged merge conflicts from all the code moving that has taken place. | 12:48 |
| jam | fwereade: so it is possible we can change it, but it is how it is written right now. | 12:48 |
| fwereade | rogpeppe, awesome, tyvm | 12:48 |
| fwereade | rogpeppe, I'm impatient to get some task actually running against the api ;) | 12:49 |
| rogpeppe | fwereade: yeah indeed | 12:49 |
| rogpeppe | fwereade: if the API hadn't been redesigned under my feet, we would already... | 12:49 |
| fwereade | rogpeppe, I'd expected that the process of getting the agent talking to the api would be independent of that, but I guess it's all distraction | 12:51 |
| rogpeppe | fwereade: it's all bound up together | 12:52 |
| fwereade | jam, but AFAICT you do in fact always have a length available at that point | 13:06 |
| fwereade | jam, it really does look a little bit like a one-line fix, although I'm not sure how pleasant it will be to test | 13:07 |
| fwereade | jam, am I missing something? | 13:07 |
| jam | fwereade: so I think the same code is used to upload multi-MB files that is used to write request data. | 13:07 |
| jam | It seems possible that we could do a normal POST for small-ish things. | 13:07 |
| jam | But if chunked is going to fail in the future, it will still fail to upload tools, etc. | 13:07 |
| jam | rogpeppe, mgz: https://code.launchpad.net/~jameinel/mgo/bug-1191487-close-race/+merge/169999 is my mgo patch that fixes the race condition for our test suite, and adds a test for the new behavior to the mgo suite as well. | 13:09 |
| rogpeppe | jam: there should be no problem using lbox even without an lbox configuration | 13:10 |
| rogpeppe | jam: lbox propose -cr -for lp:launchpad.net/mgo | 13:10 |
| jam | rogpeppe: well when I firsrt tried it told me to go shove off because it couldn't find something about mgo | 13:10 |
| jam | but this time it worked | 13:10 |
| jam | so the description should be updated | 13:10 |
| rogpeppe | jam: ah, you've got a codereview link? | 13:10 |
| jam | hmm... it found the proposal, but didn't add a CR | 13:10 |
| jam | I'll try again with -cr | 13:10 |
| jam | rogpeppe: I think the problem was I thought "lp:mgo" would be trunk, but it is not | 13:11 |
| jam | you have to propose to "lp:mgo/v2" | 13:11 |
| jam | rogpeppe: https://codereview.appspot.com/10392043/ | 13:11 |
| rogpeppe | jam: is it deliberate that you're not unlocking the server when you return from AcquireSocket? | 13:13 |
| fwereade | jam, I has a bit of a confused... what are the situations where we don't have a length available? it seems like all of goose/http expects a length to be known | 13:13 |
| jam | fwereade: so I'm actually end-of-day now, so I won't be able to poke at goose. mgz do you have a chance to see if we can make POST from goose always do Content-Length instead of chunked uploads? | 13:13 |
| jam | rogpeppe: ugh, old version of the patch | 13:13 |
| jam | rogpeppe: no it isn't | 13:13 |
| jam | it doesn't "matter" but we should unlockd | 13:14 |
| rogpeppe | jam: +1 | 13:14 |
| jam | rogpeppe: patch and proposal updated | 13:16 |
| fwereade | jam, mgz: http://golang.org/pkg/net/http/#Request has a TransferEncoding field, and the docs seems to indicate it's entirely independent of Content-Length and will magically handle chunked transfer for you | 13:19 |
| fwereade | jam, mgz: what's the downside to setting .ContentLength and letting the http package do its thing with it? | 13:21 |
| mgz | yeah, we should probably just set the length | 13:22 |
| rogpeppe1 | jam: reviewed | 13:29 |
| ahasenack | hi guys, has anyone seen this error on a unit yet? http://pastebin.ubuntu.com/5777099/ | 13:31 |
| ahasenack | that's from trunk today, fwiw | 13:31 |
| hazmat | ahasenack, yes.. i've had the same issue with trunk today | 13:32 |
| ahasenack | oh | 13:32 |
| ahasenack | I guess I should file a bug then | 13:32 |
| hazmat | ahasenack, effectively trunk is broken with it, the machines try to connect to localhost for mongo instead of back to the state servers, fwereade was looking at it | 13:32 |
| ahasenack | hazmat: is there a bug already? | 13:33 |
| fwereade | ahasenack, hazmat: sorry, several things happened, let me double-check the logs and see if it'll be simple to back out | 13:33 |
| hazmat | ahasenack, just filed one.. 1192172 | 13:34 |
| ahasenack | thanks | 13:34 |
| * hazmat goes back to vacation mode | 13:36 | |
| jam | rogpeppe1: for a 'sleep' isn't there a go function for run other goroutines rather than sleep? | 13:37 |
| jam | You're right that if I remove the log it hangs consuming cpu in that loop. | 13:37 |
| rogpeppe1 | jam: yeah, runtime.GoSched | 13:37 |
| rogpeppe1 | jam: is there a problem with calling sleep? | 13:38 |
| jam | rogpeppe1: sleep in tests is an evil source of non-determinism | 13:38 |
| rogpeppe1 | might be runtime.Gosched actually | 13:38 |
| rogpeppe1 | jam: it looks like that test is fundamentally non-deterministic anyway, no? | 13:38 |
| rogpeppe1 | jam: you're polling waiting for something to happen | 13:38 |
| jam | rogpeppe1: it is quite deterministic. | 13:38 |
| jam | I'm polling for something to converge, and then continuing | 13:39 |
| hazmat | how does the sleep change that | 13:39 |
| rogpeppe1 | jam: you might as well sleep for at least a millisecond or so while polling, or does the condition only happen momentarily? | 13:39 |
| jam | rogpeppe1: it is the length of time for a goroutine to notice a read fails on a socket after a write has failed. *Usually* (99 in 100 times) it has already finished. That loop is for the 1in100 times it fails, and log was saying it took 40microseconds. | 13:40 |
| rogpeppe1 | jam: if you're not careful, you'll spend all the time running around that loop and the actual work that you're waiting for will never be done | 13:40 |
| jam | sleep(1ms) would be ok | 13:40 |
| hazmat | sleep(0) == runtime.GoSched | 13:40 |
| rogpeppe1 | jam: sleep for 100us if you want | 13:40 |
| jam | hazmat: right, but if you do that, why not just GoSched? | 13:40 |
| jam | and be explicit | 13:41 |
| jam | rather than assume side-effect of sleep | 13:41 |
| rogpeppe1 | jam: i think a sleep makes it more explicit that you're actually waiting for something to happen | 13:41 |
| hazmat | fair enough.. sleep(0) is a pretty common pattern for coroutine systems | 13:41 |
| rogpeppe1 | jam: i'm not sure that the scheduler is guaranteed to be fair | 13:41 |
| hazmat | jam, openstack is littered with it ;-) | 13:41 |
| rogpeppe1 | jam: BTW, does newServer always return with len(unusedSocket) > 0 ? | 13:43 |
| rogpeppe1 | jam: ah yes, it looks like it | 13:46 |
| jam | rogpeppe1: no | 13:47 |
| jam | it depends what triggers the failuer | 13:47 |
| jam | socket.Write is not guaranteed to fail | 13:47 |
| jam | sometimes socket.Read fails | 13:47 |
| jam | triggering the Abend before the newServer returns | 13:47 |
| jam | that is the 99% case | 13:48 |
| jam | actually | 13:48 |
| jam | it is only infrequently that I need to loop | 13:48 |
| rogpeppe1 | jam: that's not what i was wondering about (i think). if newServer sometimes returns without an unused socket added, then you won't loop, but for the wrong reason. but since it calls pinger synchronously, i think you're guaranteed that if newServer returns without an error, the connection is there. | 13:51 |
| rogpeppe1 | jam: if you *do* loop, won't you have to wait for as long as the pinger interval? | 13:52 |
| rogpeppe1 | jam: which is presumably quite a long time. | 13:53 |
| rogpeppe1 | jam: if so, wouldn't you be better sleeping for a longer time rather than heating up the cpu waiting for the other goroutine's sleep to complete? | 13:54 |
| === wedgwood_away is now known as wedgwood | ||
| jam | rogpeppe1: I never have to wait for the pinger interval | 13:56 |
| jam | I wish it didn't ping at all | 13:56 |
| jam | but the connection will always "fail" in that I'm connecting to localhost which connects and then closes the connection (I'm not talking to Mongo in this test) | 13:56 |
| jam | the test itself completes in <1ms most of the time. | 13:57 |
| rogpeppe1 | jam: i think i've misunderstood the logic of the test entirely | 13:58 |
| jam | rogpeppe1: so the only logic it is asserting, is that if server.Close() is called while we are waiting on net.DialTCP, that AcquireSocket notices and closes the socket rather than treating it as a new alive socket. | 13:59 |
| niemeyer | jam: Thanks for catching that issue. | 13:59 |
| jam | rogpeppe1: the issue is that pinger can trigger this case, but I'm triggering it directly by calling AcquireSocket with server.dial = closeDial | 14:00 |
| jam | rogpeppe1: it happens that because newServer pings synchronously, there may-or-may-not be an unusedSocket lying around from that original ping. | 14:00 |
| === wedgwood is now known as wedgwood_away | ||
| jam | It always gets cleaned up eventually because the localhost server closes the connection on it. | 14:00 |
| fwereade | rogpeppe1, kanban | 14:02 |
| * rogpeppe1 comes in from the garden to get wi-fi signal | 14:02 | |
| niemeyer | jam: Just sent a review.. let me know if you want to talk further about it | 14:04 |
| jam | niemeyer: well, I didn't arrive at the fix because of breakage in mgo's test suite. Only from juju-core's test suite (which was quite hard to understand why it was failing with unclean threads) | 14:06 |
| jam | We could strip the test down a bit, and actually connect to mgo (not set up a local server, etc) | 14:06 |
| jam | but it would make the test a bit less isolated. | 14:06 |
| niemeyer | jam: Hmm.. interesting. I thought it was in the suite due to the "left sockets in dirty state." | 14:07 |
| niemeyer | jam: Which is a check I copied from the mgo suite | 14:07 |
| jam | niemeyer: that was the juju-core suite | 14:07 |
| jam | niemeyer: right | 14:07 |
| niemeyer | jam: Sure, but we have the same check in mgo | 14:07 |
| niemeyer | jam: What is the juju-core test doing that we don't do in mgo's? | 14:07 |
| jam | niemeyer: probably you don't have many/any tests that take longer than 10s in mog | 14:07 |
| jam | mgo | 14:07 |
| jam | niemeyer: so the pinger thread doesn't wake up | 14:07 |
| jam | at the same time the test is tearing down. | 14:07 |
| jam | (goroutine) | 14:07 |
| niemeyer | jam: There are, actually, since it takes a while for replica sets to recover, in the tests that very behavior on harsh shutdowns | 14:08 |
| jam | niemeyer: so for reproducing it, adding a sleep to the Dial code and decreasing the pingDelay made it easier to trigger directly. | 14:08 |
| jam | I didn't run the mgo test suite in anger enough times to see if it ever failed. | 14:08 |
| niemeyer | jam: We can add a sleep to the dial code externally.. I'd be fine with having a test method equivalent to one we have in juju, for tweaking down the pingDelay time | 14:09 |
| * niemeyer looks for the form used in juju | 14:10 | |
| jam | niemeyer: the test in juju is failing by accident because it is doing a lot of stuff and then pinger wakes up and leaves a stale lock | 14:10 |
| jam | and the teardown cleanup code notices there is a stale connection. | 14:10 |
| jam | (as in, it isn't testing pinger directly, etc) | 14:10 |
| jam | niemeyer: I explicitly changed the dial to call server.Close() during the dial | 14:10 |
| jam | so that it triggers at "exactly" the bad time | 14:11 |
| jam | that part I think is fairly straightforward | 14:11 |
| niemeyer | jam: Sure, that's fine.. these tests that check if there are connections hanging around are run on every single test | 14:11 |
| jam | niemeyer: right, but only tests that stop right about the time a pinger wants to wake up and check have a chance of triggering the bug | 14:12 |
| jam | and the window is pretty small | 14:12 |
| niemeyer | jam: So I'm fine without a test for this | 14:12 |
| jam | they have to wake up, ask to connect which on these machines is <10ms. | 14:12 |
| jam | niemeyer: so for your other comment, would you like to see the check taken out of the if loop: time.Sleep() code; and just put into AcquireSocket? | 14:18 |
| jam | that would remove some of the extra checks. | 14:18 |
| jam | or is it just the check for closed after the ping completes that you want to avoid | 14:18 |
| niemeyer | jam: Right, the former.. if we're checking in AcquireSocket, we can get rid of the local lock+check. | 14:20 |
| jam | niemeyer: I'm pushing an update now which: (1) Adds a check for server.closed at the start of AcquireSocket, (2) removes it from pinger, (3) removes server_test.go (though I did check it still passed with the new code) | 14:32 |
| niemeyer | jam: Super, will check it out | 14:32 |
| ahasenack | fwereade: hazmat: reverting to r1291 fixed it for me for now | 14:36 |
| ahasenack | but you probably know that already ;) | 14:36 |
| FunnyLookinHat | So - is there an easy way to take the image I'm booting with KVM and my own custom user-data and snapshot it so I can throw it into my own OpenStack for testing? Built with this: https://help.ubuntu.com/community/UEC/Images#Ubuntu_Cloud_Guest_images_on_12.04_LTS_.28Precise.29_and_beyond_using_NoCloud | 14:38 |
| hazmat | FunnyLookinHat, probably a better question for #ubuntu-server | 14:38 |
| FunnyLookinHat | hazmat, good call. | 14:39 |
| fwereade | rogpeppe2, TheMue: can I get an LGTM on https://codereview.appspot.com/10391045 (which just reverts r1292) please? | 14:48 |
| rvba | TheMue: my branch https://codereview.appspot.com/10380043/ is not landing although I marked the MP approved… did I miss something? Do I need to approve it myself to have two LGTM? | 14:49 |
| fwereade | rvba, have you set a commit message? | 14:49 |
| rvba | fwereade: arg, that must be it, it's a classic :). Thanks. | 14:49 |
| rogpeppe2 | fwereade: looking | 14:49 |
| TheMue | fwereade: will look | 14:52 |
| rogpeppe2 | fwereade: which was the problematic bit? the changes in provisioner_task.go ? | 14:52 |
| fwereade | rogpeppe2, specifically, we started getting addresses from state rather than the environ, I think | 14:52 |
| fwereade | rogpeppe2, the previous form has problems too | 14:53 |
| rogpeppe2 | fwereade: yeah, that's what i thought. i was just looking for how provisionerTask.stateInfo actually gets set | 14:53 |
| fwereade | rogpeppe2, but they're strictly less bad than not being able to deploy anywhere other than machine 0 | 14:54 |
| rogpeppe2 | :-) | 14:54 |
| rogpeppe2 | fwereade: ah, i see | 14:55 |
| rogpeppe2 | fwereade: the problem is that we don't actually store the state.Info in the state | 14:55 |
| rogpeppe2 | fwereade: wouldn't that be a better fix? | 14:55 |
| fwereade | would it be? that'd still get us unwanted localhosts | 14:55 |
| fwereade | rogpeppe2, I think | 14:56 |
| rogpeppe2 | fwereade: i don't think do. not if we make sure that we use the result of Environ.StateInfo to pass to state.SetInfo | 14:57 |
| rogpeppe2 | s/do/so | 14:57 |
| rogpeppe2 | fwereade: the current problem is that state.Addrs is returning the same addresses that it used to connect | 14:57 |
| rogpeppe2 | s/Addrs/Addresses/ | 14:58 |
| fwereade | rogpeppe2, it's returning whatever LiveServers tells it | 14:59 |
| fwereade | rogpeppe2, I absolutely agree that the "fix" I have proposed is not a fix | 14:59 |
| rogpeppe2 | fwereade: oh yeah | 14:59 |
| rogpeppe2 | fwereade: that's still wrong though | 14:59 |
| rogpeppe2 | fwereade: fair enough. | 15:00 |
| rogpeppe2 | fwereade: revert away; the right fix is probably not that trivial | 15:00 |
| fwereade | rogpeppe2, I'll be talking to tim about it; I think it'll involve some machine addressability work to get it right | 15:00 |
| fwereade | rogpeppe2, but maybe only a little before it's adequate | 15:01 |
| rogpeppe2 | fwereade: a quick fix would be to use Environ.StateInfo as previous. the addressability work can probably wait until we're actually doing HA | 15:02 |
| fwereade | rogpeppe2, I don't see how that would help... we still connect to localhost on the bootstrap node, so localhost will be in the state info | 15:02 |
| fwereade | rogpeppe2, the addressability work cannot wait, it's bound up with containers | 15:03 |
| rogpeppe2 | fwereade: the environ does a host lookup to get the stateinfo address, doesn't it? | 15:03 |
| rogpeppe2 | fwereade: that's why things work currently | 15:03 |
| fwereade | rogpeppe2, the *environ* does, yeah, but the reason *juju* works currently is that it uses the info from the environ, not the one from state | 15:04 |
| fwereade | rogpeppe2, or rather, the reason it doesn't work is the opposite | 15:05 |
| fwereade | rogpeppe2, and this change restores the happy variant | 15:05 |
| fwereade | rogpeppe2, we will indeed need more work in this area | 15:05 |
| fwereade | rogpeppe2, but for now I'd just like to have a working trunk | 15:06 |
| rogpeppe2 | fwereade: exactly. i think that's what i was suggesting - when the provisioner comes up, it calls state.SetStateInfo with the results of environ.StateInfo | 15:06 |
| rogpeppe2 | fwereade: +1 | 15:06 |
| rogpeppe2 | fwereade: (not that there *is* a SetStateInfo call currently, of course) | 15:06 |
| rogpeppe2 | hmm, it probably wouldn't be SetStateInfo; probably SetStateServerAddresses or something | 15:07 |
| fwereade | rogpeppe2, yeah, something like that -- but actually having those addresses set on the machine objects would be quite nice too | 15:07 |
| fwereade | rogpeppe2, that said, your suggestion does mean it'll work for the GUI on machines-other-than-0, so I will pass that along; cheers | 15:08 |
| rogpeppe2 | fwereade: yeah, it would be good to have addresses associated with machines in the state. | 15:10 |
| rogpeppe2 | fwereade: i think i proposed a worker for that in my HA sketch | 15:10 |
| niemeyer | jam: I've tagged the fixed revision, btw | 15:11 |
| === rogpeppe2 is now known as rogpeppe | ||
| niemeyer | jam: So updates will already pick the fix, although I'll announce with the new release | 15:12 |
| fwereade | jam, hey, if you set a commit message on an approved MP that tarmac has previously ignored, will it reliably pick it up then? | 15:21 |
| === niemeyer__ is now known as niemeyer | ||
| fwereade | ahasenack, hazmat: trunk should bootstrap again, and should in a few minutes bootstrap with 1.10 again, tarmac willing | 15:51 |
| ahasenack | fwereade: thanks | 15:51 |
| hazmat | fwereade, awesome | 15:55 |
| jtv | I've got one of these situations where every error return from my function can prefix the same context string onto the error message... Would it be terrible of me to move that into a helper function like this? https://codereview.appspot.com/10361047 | 16:09 |
| rogpeppe | jeeze everything about this machine has become incredibly flaky. the display, the wi-fi, youtube fullscreen, multiscreen. i wonder how much is hardware and how much is software | 16:12 |
| jtv | Not fun debugging those problems. | 16:15 |
| rogpeppe | jtv: you don't recognise this sequence from syslog by any chance, do you? sometimes it gets itself into a mode where this repeats forever without successfully connecting to the network it actually knows the correct password for. http://paste.ubuntu.com/5777587/ | 16:30 |
| rogpeppe | jtv: i *think* it usually happens when i've been switching between wi-fi hubs quite a bit | 16:31 |
| FunnyLookinHat | rogpeppe, what sort of machine? | 16:32 |
| rogpeppe | FunnyLookinHat: lenovo thinkpad x220 | 16:32 |
| FunnyLookinHat | Ah, well there's your problem... ;) | 16:32 |
| FunnyLookinHat | jk - that surprises me. Intel graphics, yes? | 16:32 |
| FunnyLookinHat | And probably wireless as well... | 16:32 |
| rogpeppe | FunnyLookinHat: i was told it was one of best supported laptops. | 16:33 |
| rogpeppe | FunnyLookinHat: oh well | 16:33 |
| rogpeppe | FunnyLookinHat: it's been stable for two years. i've only seen these problems after upgrading to raring | 16:34 |
| FunnyLookinHat | Ah strange. Well - time to upgrade... :) https://www.system76.com/laptops/model/galu1 | 16:36 |
| rogpeppe | FunnyLookinHat: i've been meaning to reinstall from scratch to see if that helps, but i can't quite bring myself to lose a week fixing everything that i will inevitably have lost in the process. | 16:36 |
| rogpeppe | FunnyLookinHat: no good - i need three buttons | 16:37 |
| FunnyLookinHat | Fair enough - I was the same way ( used to be a ThinkPad guy ) and loved the eraser and all... I just got over it eventually :) | 16:38 |
| rogpeppe | FunnyLookinHat: i use the world's strangest editor, which really really needs a three-button mouse. | 16:38 |
| FunnyLookinHat | rogpeppe, PEBCAK ! :) What editor? | 16:39 |
| rogpeppe | FunnyLookinHat: http://research.swtch.com/acme | 16:40 |
| FunnyLookinHat | Ah interesting - thx for the link | 16:41 |
| rogpeppe | FunnyLookinHat: what i really want is a laptop with a display that works well in full sunlight | 16:43 |
| benji | rogpeppe: you live in the UK and expect us to believe you have ever seen full sunlight? | 16:43 |
| rogpeppe | lol | 16:44 |
| benji | ;) | 16:44 |
| rogpeppe | benji: i have to take advantage of whatever we have | 16:44 |
| benji | heh | 16:44 |
| FunnyLookinHat | haha | 16:44 |
| rogpeppe | benji: hence i'm out in the garden currently | 16:44 |
| rogpeppe | benji: because the sun is almost out | 16:45 |
| rogpeppe | benji: and that's what triggered my wi-fi issues because i have to switch to phone data out here because the landline hub doesn't stretch this far | 16:45 |
| benji | honestly your weather is probably better than mine today, it's raining on and off and I'm sitting outside anyway (under a covered porch) | 16:46 |
| benji | we should start a line of weatherproof outdoor wifi boosters | 16:46 |
| rogpeppe | benji: last couple of days it's been absolutely gorgeous. when british weather is good, it's wonderful | 16:46 |
| benji | :) | 16:46 |
| rogpeppe | benji: it only happens about 3 days a year tho | 16:46 |
| benji | what is it the British say about how great summer is there: it's their favorite day of the year | 16:47 |
| benji | it's all good though, come August I'll be sweltering in near 100% humidity, so I have to poke fun while I can | 16:48 |
| jtv | rogpeppe: I don't recognize the sequence, but my wifi isn't working very well either... | 16:52 |
| * jtv looks | 16:53 | |
| jtv | Nope, my log looks very different. | 16:55 |
| jtv | Would anybody be willing to review my little error-context helper? It's at https://codereview.appspot.com/10361047 | 16:56 |
| rogpeppe | jtv: we have something very similar called ErrorContextf in juju-core | 17:01 |
| jtv | Ah great | 17:01 |
| jtv | I looked for other similar "defer" calls, but didn't see it. | 17:01 |
| jtv | Maybe I only looked in the providers. | 17:01 |
| rogpeppe | jtv: i have mixed feelings about it in general | 17:01 |
| jtv | I think it's something to be seen as a utility, not as a universal element in all error handling. | 17:02 |
| jtv | There are clearly places where it's not appropriate. | 17:02 |
| jtv | I'll scupper this branch then, thanks! | 17:03 |
| rogpeppe | jtv: but that's because i think we do our error messages a bit wrong in general. i reckon error messages to tell you about what went wrong, not about what function you're calling (you know that, in general) | 17:03 |
| rogpeppe | jtv: see utils.ErrorContextf | 17:04 |
| jtv | Yes, looking at it now. | 17:04 |
| * rogpeppe has to go. | 17:04 | |
| jtv | nn | 17:04 |
| rogpeppe | g'night all | 17:04 |
| rogpeppe | jtv: see ya | 17:04 |
| jtv | nnnn | 17:04 |
| jtv | (weird keyboard) | 17:04 |
| TheMue | so, synctools change is in for review, have a good night | 17:56 |
| === BradCrittenden is now known as bac | ||
| === deryck_ is now known as deryck | ||
| thumper | fwereade: ping | 21:23 |
| fwereade | thumper, pong | 21:24 |
| thumper | fwereade: what was wrong with the provisioner branch? | 21:24 |
| thumper | I'm not sure how the localhost thing is three | 21:24 |
| thumper | there | 21:24 |
| fwereade | thumper, I'm an idiot, I forgot that State.Addresses would return a localhost address if that was how the connection was made | 21:25 |
| thumper | ah... | 21:25 |
| thumper | well that is a bit screwy | 21:25 |
| thumper | how should we address that? | 21:25 |
| fwereade | thumper, yeah, there are better ways and worse ways of addressing it, but the sensible ones all seem to demand a bit of machine adddressability | 21:26 |
| thumper | heh | 21:26 |
| fwereade | thumper, I spoke to mgz, and the first step is apparently to clone the unit addressing stuff onto machine | 21:26 |
| * thumper nods | 21:26 | |
| thumper | so, should we attempt to fix this branch now | 21:27 |
| thumper | or just wait until some addressability bits are done | 21:27 |
| fwereade | thumper, and then, if we have a machine agent running, we'll have an address for the machine, and everything will be good | 21:27 |
| fwereade | thumper, because we should be able to get the management machines out of state very easily | 21:28 |
| thumper | fwereade: do you have some time for a quick hangout? | 21:28 |
| fwereade | thumper, sure | 21:29 |
| wallyworld_ | thumper: s'up | 22:19 |
| thumper | wallyworld_: hey, OTP with fwereade right now | 22:22 |
| wallyworld_ | kk | 22:22 |
| wallyworld_ | thumper: tell fwereade to go to bed or else he will turn into a pumpkin | 22:23 |
| thumper | something amusing from twitter yesterday: RT @qntm: "I love stateless systems." "Don't they have drawbacks?" "Don't what have drawbacks?" | 22:24 |
| wallyworld_ | lol | 22:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!