| jam | wallyworld: you're running a juju test right now, correct? | 06:56 |
|---|---|---|
| wallyworld | jam: yes | 07:04 |
| wallyworld | it just finished | 07:04 |
| jam | wallyworld: not a problem, just saw some active images and wanted to double check. | 07:05 |
| wallyworld | jam: i'm checking also - i'm about to kill those since they are left over | 07:06 |
| wallyworld | i've run a lot of live tests today | 07:06 |
| wallyworld | finally got them passing | 07:06 |
| jam | wallyworld: np, I'm just starting one up myself, but it is a t1.micro for some testing. | 07:06 |
| jam | wallyworld: great to hear that you got them passing. | 07:06 |
| jam | Now, we just need to get them continually passing :) | 07:06 |
| wallyworld | yep :-) plus they take soooooo long | 07:07 |
| wallyworld | so the code/test cycle blew out a bit | 07:07 |
| wallyworld | jam: just to make 100% sure - i've terminated all my mediums and left a micro running | 07:08 |
| jam | sounds good | 07:08 |
| jam | wallyworld: yeah. I understand. I wonder how much of that is required. I guess some of the time is that EC2 takes a bit longer to spin things up? | 07:09 |
| jam | morning dimitern | 07:09 |
| dimitern | morning all | 07:09 |
| jam | wallyworld: though also the local "live" tests are also quite a bit slower on ec2 because of the automatic S3 consistency retry code. | 07:10 |
| wallyworld | jam: i haven't profiled it but i do think spin up time accounts for a lot, as it seems to run through stuff ok (but a little slow) once the instance is running | 07:10 |
| wallyworld | fwereade: hi there, i'm off to soccer training for a few hours. perhaps while i'm gone you could look at my latest ec2 live test fixes mp. there's one thing i'm not 2100% sure on - i've commented in the cover letter | 07:21 |
| fwereade | wallyworld, will do | 07:21 |
| wallyworld | thanks. talk later | 07:21 |
| fwereade | wallyworld, but I only demand 1800% certainty ;p | 07:21 |
| wallyworld | typo! | 07:21 |
| === rvba` is now known as rvba | ||
| dimitern | fwereade: so api work is on now, right? | 08:05 |
| fwereade | dimitern, yeah, that's top of the list | 08:06 |
| fwereade | dimitern, is rog around today, do you know? | 08:06 |
| dimitern | fwereade: i'm not aware he's away at least | 08:07 |
| dimitern | go 1.1 is released now, so I'm switching to it (as we all should) | 08:07 |
| fwereade | dimitern, +1 | 08:08 |
| fwereade | hey, does the "Title" field in a charm.Option ring any bells with anyone? | 08:21 |
| rogpeppe2 | mornin' all | 08:22 |
| === rogpeppe2 is now known as rogpeppe | ||
| dimitern | rogpeppe: morning | 08:22 |
| dimitern | fwereade: what's "change agents to use API connection where available"? how could it be unavailable? | 08:24 |
| jam | dimitern: I believe that means "where there is an API that has been written, make sure agents are using the API rather than direct DB access" | 08:27 |
| fwereade | dimitern, jam, sorry that was unclear | 08:28 |
| dimitern | jam: I see ok | 08:28 |
| fwereade | dimitern, jam: I don't think an API connection *is* generally available though | 08:28 |
| dimitern | fwereade: but it must, eventually | 08:28 |
| fwereade | dimitern, jam: *maybe* we always write sensible API info | 08:28 |
| fwereade | dimitern, yeah, that step is really just "make sure that we always start an API connection" | 08:29 |
| fwereade | dimitern, with a side order of "hmm, what if we're an API server" | 08:29 |
| dimitern | fwereade: ok, it looks like a good candidate for a card | 08:29 |
| jam | fwereade: we do always set APIInfo in the start instance code. | 08:30 |
| fwereade | dimitern, sgtm | 08:30 |
| dimitern | btw i'm getting test failures in trunk after a fresh rebuild with go1.1 - http://paste.ubuntu.com/5666973/ | 08:30 |
| fwereade | jam, ok, cool -- but I'm not sure that all the pieces are actually joined up, just that the environs probably do the right thing does not imply anything about either the input or the agent itself | 08:31 |
| jam | dimitern: it looks like you're getting a panic running Main which obviously means you don't get 'help' and changes the return code. | 08:31 |
| dimitern | jam: i was thinking these tests rely on having jujud binaries - i did go install and running the tests again | 08:32 |
| dimitern | nah, still the same failures | 08:38 |
| dimitern | anyone seen these or should i file a bug? | 08:38 |
| dimitern | (any why does it say $GOPATH not set when it is set?!) | 08:39 |
| jam | dimitern: is the test suite isolating it from us? | 08:47 |
| dimitern | jam: not sure what do you mean - but running the tests in isolation produces the same errors | 08:49 |
| rogpeppe | dimitern: hmm, odd | 08:50 |
| jam | dimitern: I mean that the test suite infrastructure is sanitizing environment variables | 08:50 |
| jam | like GOPATH | 08:50 |
| jam | though given the 'build' (?) package, you'd think we'd need it. | 08:50 |
| rogpeppe | jam: yes, i'm wondering that | 08:50 |
| dimitern | jam: that's possible but a silly thing to do :) | 08:50 |
| rogpeppe | jam: but i don't have a problem, i don't think | 08:50 |
| rogpeppe | will try again | 08:50 |
| jam | it is usually good to sanitize some variables, but GOPATH seems foolish to change. | 08:51 |
| dimitern | that's go 1.1 specific perhaps? | 08:51 |
| jam | dimitern: I think just tracking into the panic is likely to be fruitful, but if GOPATH is getting unset that looks worrying, too. | 08:51 |
| dimitern | although on friday I was running on go1.1rc3 all the tests from a fresh build & checkout w/o any errors | 08:51 |
| dimitern | jam: i'll take a look what got landed since then first | 08:52 |
| jam | dimitern: certainly if they were using normal "Release Candidate" naming, nothing should land but a version bump. | 08:52 |
| jam | otherwise they should have had a new "candidate" | 08:53 |
| jam | but I don't know go core policy | 08:53 |
| rogpeppe | jam: yes, i think that's what happened. | 08:53 |
| rogpeppe | jam: rc3 became 1.1 | 08:53 |
| dimitern | jam: no i mean i need to see what changed in juju since friday so it fails now, whereas it wasn't failing with 1.1rc3 on friday | 08:54 |
| jam | ah, sure | 08:55 |
| rogpeppe | all jujud tests pass for me against 1.1 | 08:56 |
| dimitern | rogpeppe: yeah, i also suspect my setup could be somehow wrong: i have ~/go/1.1/ (goroot); ~/work/go/1.1/ (gopath) both set and ~/src/1.1/juju-core (symlink to gopath/src/lp.net/juju-core) | 08:58 |
| rogpeppe | dimitern: something looks very odd | 09:02 |
| rogpeppe | dimitern: that traceback looks fishy | 09:02 |
| rogpeppe | dimitern: have you tried removing $GOPATH/pkg and recompiling? | 09:03 |
| dimitern | rogpeppe: no, i'll try - however everything was clean when I started (created the dirs empty and then rebuilt 1.1 then go get -u lp/juju-core/..., etc) | 09:05 |
| rogpeppe | dimitern: what happens if you do "go test -i" in cmd/jujud ? | 09:05 |
| mgz | jam: will have to miss standup today, have appointment in town across it | 09:06 |
| dimitern | rogpeppe: completes in a couple of seconds w/o errors | 09:06 |
| dimitern | rogpeppe: still running the full test suite though | 09:07 |
| dimitern | rogpeppe: still the same failures | 09:09 |
| rogpeppe | dimitern: is that the only package that fails? | 09:10 |
| dimitern | rogpeppe: yes | 09:10 |
| rogpeppe | dimitern: that's very odd, because lots of other packages import juju-core/testing, and it's an init function in there that's failing | 09:11 |
| rogpeppe | dimitern: how about putting a printf in testing/charm.go, in the init function that calls build.Import ? | 09:12 |
| dimitern | rogpeppe: i don't think the problem is not finding testing at all - it some weird way of invoking the commands that screws up the env vars | 09:12 |
| rogpeppe | dimitern: print the value of os.Getenv("GOPATH") and perhaps os.Getenv("GOROOT") too | 09:12 |
| rogpeppe | dimitern: ah, i see the problem | 09:15 |
| rogpeppe | dimitern: hmm, maybe not | 09:15 |
| dimitern | rogpeppe: nothing is printed out with the failures | 09:16 |
| dimitern | fmt.Printf(">>> GOPATH = %s; GOROOT = %s\n", os.Getenv("GOPATH"), os.Getenv("GOROOT")) | 09:16 |
| dimitern | added that as a first line in init() in testing/charm.go | 09:16 |
| rogpeppe | dimitern: what do you see if you add a string to the panic in check. (e.g. panic(fmt.Errorf("check failed: %v", err))) ? | 09:17 |
| rogpeppe | dimitern: if you don't see the extra string, there's something odd going on | 09:17 |
| dimitern | rogpeppe: checking | 09:19 |
| rogpeppe | dimitern: it might also be worth printing the value of ps.Env in jujud.run | 09:20 |
| rogpeppe | dimitern: to make sure it looks sane | 09:20 |
| dimitern | rogpeppe: nothing; i think that's not the check() that gets called - it's in cmd/jujud/_test/jujud.test | 09:22 |
| rogpeppe | dimitern: i'm not sure what you mean there | 09:23 |
| === ehg_ is now known as ehg | ||
| rogpeppe | dimitern: so you're saying you don't see the extra "check failed" message? | 09:27 |
| dimitern | rogpeppe: just a sec | 09:27 |
| dimitern | rogpeppe: my emacs setup was not finding gofmt and not saving the files :| | 09:27 |
| rogpeppe | dimitern: ah, that might explain some things :-) | 09:28 |
| fwereade | jam, responded on https://codereview.appspot.com/9175043/ - let me know if anything's clearly insane ;p | 09:29 |
| rogpeppe | anyone know how i can change which browser gets started by default when i click on a link outside the browser, BTW? since i upgraded to raring, it's always choosing firefox and i want chrome | 09:30 |
| mgz | rogpeppe: should be settable under default applications, see askubuntu google results | 09:33 |
| rogpeppe | mgz: i couldn't think of a decent search term | 09:33 |
| mgz | there are like, four different underlying mechanisms | 09:33 |
| rogpeppe | mgz: ah, System->Details! | 09:35 |
| rogpeppe | mgz: that's a bloody obscure place to keep it | 09:35 |
| rogpeppe | mgz: hmm, my default browser *is* chrome | 09:35 |
| rogpeppe | mgz: i guess one of the other mechanisms is kicking in | 09:36 |
| mgz | so, you can also check `update-alternatives --config x-www-browser`, the $BROWSER envvar, and mime types if you get desperate | 09:38 |
| rogpeppe | mgz: update-alternatives prints this: http://paste.ubuntu.com/5667132/ (i.e. it looks like chrome is the default, although i don't know what "manual mode" is) | 09:50 |
| rogpeppe | mgz: $BROWSER isn't set | 09:50 |
| rogpeppe | mgz: i'm not sure how mime types would come into play when clicking a link in my irc browser | 09:50 |
| jam | rogpeppe: is your irc in a browser already? Or perhaps a Mozilla based one? | 09:51 |
| rogpeppe | jam: no. i use Konversation | 09:51 |
| rogpeppe | jam: and it worked fine before upgrading | 09:52 |
| jam | rogpeppe: http://docs.kde.org/stable/en/extragear-network/konversation/webbrowser.html ? | 09:52 |
| rogpeppe | jam: good catch, thanks! | 09:53 |
| rogpeppe | jam: yeah, that works | 09:54 |
| rogpeppe | jam: i wonder why it changed | 09:54 |
| jam | rogpeppe: did you have to set a new one, or was something already set? | 09:54 |
| rogpeppe | jam: "use a custom browser" was unchecked, but the text in grey said "firefox" | 09:55 |
| rogpeppe | jam: i looked at that settings panel too - just missed the setting | 09:55 |
| jam | fwereade: so why is a slice + channel for a "self mutexed" variable better than just putting a mutex around the variable? | 10:37 |
| jam | I'm a little confused by your statement that it is good for N goroutines, but then follow it up with "more than one goroutine renders this technique worthless" | 10:37 |
| fwereade | jam, the testing is worthless if you don't know what transaction you'll be trying to run -- but the code itself does in fact have to work in concurrent conditions | 10:46 |
| fwereade | jam, I could plausibly instead switch out a transaction runner at test time, but that felt like an additional layer for not much benefit | 10:47 |
| fwereade | jam, wrt the one-buffered channel it just ...seemed cleaner to me | 10:48 |
| fwereade | jam, lock/change/unlock/lock/change/unlock feels like more work and easier to mess up that pop/push/pop/push | 10:49 |
| jam | fwereade: so I don't quite understand why you need to set it to nil when you aren't sure that you're actually done with the thing, I think that is my big sticking point. | 10:51 |
| jam | especially setting it to nil, only to pop that back off again once you start actually doing something. | 10:51 |
| fwereade | jam, I need to set it to nil while the hooks are run so that they can themselves run transactions | 10:51 |
| jam | fwereade: what happened to only 1 transaction under test? | 10:51 |
| fwereade | jam, ...that's the point | 10:52 |
| fwereade | jam, there is only one transaction under test | 10:52 |
| jam | fwereade: so you're missing my point, then. | 10:52 |
| jam | yes, you should only test 1 transaction per test case. | 10:52 |
| fwereade | jam, sounds like ) | 10:52 |
| jam | but you should be explicit about which one you are testing during the test | 10:52 |
| jam | in case the specific ordering of actual transactions | 10:52 |
| jam | changes | 10:52 |
| jam | and things suddenly pass/fail for odd reasons. | 10:52 |
| jam | (be explicit so side effects don't confuse you) | 10:52 |
| jam | if multiple transactions are occurring during the test case | 10:53 |
| fwereade | jam, I'm not sure what sort of situation you're describing | 10:53 |
| jam | then your method only allows you to ever test the "first" transaction hit. | 10:54 |
| jam | if the code ever changes | 10:54 |
| jam | and order of operations (say a new action is done) | 10:54 |
| jam | then the test breaks which might be hard to reason about why | 10:54 |
| jam | or it doesn't break | 10:54 |
| fwereade | jam, where do we use multiple transactions in a state method (that aren't obviously wrong, and candidates for fixing)? | 10:54 |
| jam | but you stop testing what you thought you were. | 10:54 |
| jam | fwereade: you just said "I need to set it to nil so that they can run transations" | 10:54 |
| jam | is that so the hooks themselves, but not other code. | 10:55 |
| jam | I think I misread that sentence. | 10:55 |
| fwereade | jam, how should I break state for the txn under test *wuthout* running others? | 10:55 |
| jam | I thought it was "so that stuff going on during the transaction can run transations" | 10:55 |
| jam | fwereade: well, since TXN is purely opt-in, you could always break the DB at any time :) | 10:55 |
| fwereade | jam, ah sorry no -- I just mean so that the hooks themselves can run transactions | 10:55 |
| fwereade | jam, not in a useful way, though, I think | 10:55 |
| jam | however, that is a moot point, though a potentially interesting tangent. | 10:56 |
| jam | anyway. I'm still generally in favor of getting an error of the form "the transaction you thought you were testing is not the one that is being run" rather than "did not get ErrAborted" | 10:57 |
| fwereade | jam, I did ponder passing ops into the hooks, but I thought that'd probably encourage overly brittle testing | 10:58 |
| fwereade | jam, and I'm not sure what if anything the hook name would tell you -- I'm probably misunderstanding again | 10:58 |
| jam | fwereade: I like having arbitrary callbacks personally. Since you may need to do some inspection/etc rather than just ops on the db | 10:58 |
| jam | fwereade: so the "runTxn" function would become "runTxn(name string, ops []txn.Ops)" | 10:59 |
| jam | and the hooks would get a descriptor of what name they are associated with | 10:59 |
| jam | and you would get a direct error/panic if runTxn was running something that didn't match the name in the hook. | 10:59 |
| jam | (in other systems, I just wouldn't run the hooks, but you mention you want to be clear that only 1 transaction is ever running under test) | 11:00 |
| fwereade | jam, that's more a goal statement than a position statement, but offhand I'm not sure how bad we are there | 11:01 |
| jam | fwereade: anyway, your system is fine (as I'm pretty sure I've stated). I think I'm being a bit overbroad about an idea of having hooks executing before and after transactions, in which case you want to name the thing you are running before or after. | 11:01 |
| fwereade | jam, hmm, I do *kinda* like the idea of naming transactions but I'd prefer to let it marinate a bit | 11:04 |
| jam | fwereade: another small bit is the "one transaction run" rule, which is slightly violated by the design. In that you have a chain of before/after/before/after. | 11:05 |
| jam | And in your current method | 11:05 |
| jam | those "should" be the same transaction being run in a loop | 11:05 |
| jam | because that is how you are testing it | 11:05 |
| fwereade | jam, same transaction doesn't imply same ops | 11:06 |
| jam | fwereade: sure, but my point is, the design is perfectly amenable to "run txn A, then txn B, then txn C" | 11:06 |
| jam | except it doesn't actually track that | 11:06 |
| jam | (as in, you could use the structure you set forth to test a function which ran 3 separate transactions linearly) | 11:07 |
| jam | but if the code underneath changed from A B C to A C B the test infrastructure is all lined up | 11:07 |
| jam | but the assertions all break | 11:07 |
| jam | and it could be helpful if you were informed directly about the precondintions (A B C) being violated. | 11:07 |
| fwereade | jam, my point is that a state method doing A B C is Doing It Wrong | 11:08 |
| fwereade | jam, and that testing 3 state methods in one go is kinda pointless | 11:08 |
| jam | fwereade: in which case, having an assertion that you *aren't* doing A B C seems like a win as well | 11:08 |
| fwereade | jam, not sure how I'd do that... | 11:09 |
| jam | fwereade: as I said before, what you did works, and is better than not having it. I'm happy to have a discussion about ways I think it could be better. | 11:09 |
| jam | fwereade: if you name the transactions, then the thing that installs the hook names it | 11:09 |
| jam | then you just check the name matches | 11:09 |
| fwereade | jam, (that's what I think we're doing :)) | 11:09 |
| jam | fwereade: right. a couple of your statements made it feel like I was blocking you, which I'm not trying to do. | 11:10 |
| fwereade | jam, ah, sorry, not intended | 11:10 |
| fwereade | jam, I'm just not 100% sure that named transactions really help all that much... but nor am I sure they hurt that much either ;) | 11:12 |
| fwereade | jam, I expect we'll figure out what really work in practice when we try to write tests for the cases I haven't thought of yet ;) | 11:13 |
| jam | fwereade: so. I think my point boils down to, if doing X is "Doing it Wrong" lets try to add bits into the system to make it hard to "Do it Wrong" rather than trusting that we'll catch it in review, etc. | 11:18 |
| jam | wallyworld, dimitern: ping for standup | 11:30 |
| dimitern | jam: just a sec | 11:31 |
| dimitern | rogpeppe: how is the errors package going? | 11:37 |
| rogpeppe | dimitern: i'm hoping to write the tests later today - i'm just polishing up my rpc package changes to propose | 11:37 |
| dimitern | rogpeppe: ah ok, can't wait to start using it! :) | 11:38 |
| rogpeppe | dimitern: here\'s the doc for the revamped rpc API BTW. feedback appreciated: http://paste.ubuntu.com/5667354/ | 11:39 |
| wallyworld | rogpeppe: hey, when you get a spare moment (or are bored), could you take another look at the simplestreams stuff. i think/hope i've covered all the necessary fixes etc. | 11:58 |
| rogpeppe | wallyworld: will do | 11:58 |
| wallyworld | thanks. there's now 4 branches to potentially look at :-) | 11:58 |
| wallyworld | i'll land them all at once | 11:59 |
| rogpeppe | wallyworld: could you give me links to them in pipeline order, please? | 11:59 |
| wallyworld | rogpeppe: | 12:00 |
| wallyworld | https://codereview.appspot.com/9138044/ | 12:00 |
| wallyworld | https://codereview.appspot.com/9128047/ | 12:00 |
| wallyworld | https://codereview.appspot.com/9130044/ | 12:00 |
| wallyworld | https://codereview.appspot.com/9419047/ | 12:00 |
| wallyworld | thanks :-) | 12:00 |
| rogpeppe | wallyworld: ta | 12:00 |
| rogpeppe | fwereade, dimitern, jam: reviews appreciated - i *think* this is a significant improvement. https://codereview.appspot.com/9410043 | 12:40 |
| dimitern | rogpeppe: looking | 12:41 |
| === wedgwood_away is now known as wedgwood | ||
| mramm | morning everybody | 13:49 |
| mgz | morning mramm | 13:50 |
| mramm | friendly neighborhood reminder: kanban board review in 10 min | 13:51 |
| dimitern | is this the link? https://plus.google.com/hangouts/_/539f4239bf2fd8f454b789d64cd7307166bc9083 | 14:01 |
| mramm | dimitern: yes | 14:03 |
| mramm | rogpeppe: ^^^^ | 14:03 |
| rogpeppe | dimitern, fwereade: https://codereview.appspot.com/9426045 | 15:36 |
| dimitern | rogpeppe: ah cool! | 15:36 |
| rogpeppe | dimitern: did you get any further with the rpc review? | 15:38 |
| dimitern | rogpeppe: will be done shortly, sorry got distracted a bit | 15:39 |
| rogpeppe | dimitern: np | 15:39 |
| rogpeppe | i'm taking a lunch break now. back soon. | 15:39 |
| rogpeppe | back | 16:15 |
| mgz | late lunch :) | 16:16 |
| dimitern | rogpeppe: 2 reviews done | 16:37 |
| rogpeppe | dimitern: thanks! | 16:37 |
| rogpeppe | right, that's me for the day | 17:27 |
| rogpeppe | g'night all | 17:27 |
| mattyw | QUESTION: I'm a bit confused by the idea of the contrib directory. Are we saying this is where contributers would merge to, and then it would get taken into 'main' when it was deemed ready? | 18:16 |
| mattyw | sorry - wrong place :( | 18:16 |
| === Makyo is now known as Makyo|out | ||
| === BradCrittenden is now known as bac | ||
| === wedgwood is now known as wedgwood_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!