[00:03] <SpamapS> Heh.. seems like we should write a Gobot
[00:03] <SpamapS> http://www.toyarchive.com/Gobots/GobotsPic2.gif
[00:03] <SpamapS> tho we might get into some hairy trademark area ;)
[08:39] <_mup_> Bug #887919 was filed: Juju environment option to specify SSH key? <juju:New> < https://launchpad.net/bugs/887919 >
[11:56] <rog> fwereade: mornin'
[12:01] <niemeyer> Yo
[12:26] <hazmat> g'morning
[12:36] <fwereade> heya rog, niemeyer, hazmat
[12:42] <rog> niemeyer, hazmat: mornin'
[12:43] <rog> niemeyer: somewhat simpler jujutest package interface: http://paste.ubuntu.com/733042/
[12:44] <niemeyer> rog: Why is that needed?
[12:44] <rog> niemeyer: where do the tests get defined?
[12:44] <niemeyer> rog: As far as I understand, we only need a type
[12:44] <rog> niemeyer: that's the type
[12:44] <niemeyer> rog: ProviderTests
[12:45] <rog> i though jujutests.Tests
[12:45] <niemeyer> rog: and what's Name and Value for?
[12:45] <niemeyer> rog: This should be within the tests as far as I understand
[12:45] <rog> niemeyer: it's so we can write tests that call Open twice to check persistance of a juju session
[12:45] <niemeyer> rog: am I missing something there?
[12:46] <rog> another possibility would be to pass ProviderFactory func() juju.Provider
[12:47] <niemeyer> rog: Hmm, no that sounds fine
[12:47] <niemeyer> rog: But I still don't get what's Value
[12:47] <niemeyer> rog: Is it Config?
[12:47] <rog> niemeyer: yeah, that would be a better name
[12:47] <niemeyer> rog: Aha, I see the picture now, thanks
[12:47] <niemeyer> rog: +1
[12:47] <rog> cool
[12:48] <rog> niemeyer: i think i'll stick with Tests as a name until we want more than one suite.
[12:48] <niemeyer> rog: Sounds good
[12:49] <marcoceppi> Is there any way, during config-changed, to extract the value prior to change?
[12:49] <marcoceppi> Good morning, btw
[12:50] <niemeyer> marcoceppi: Morning
[12:50] <niemeyer> marcoceppi: Not with a standard variable, but you can do that trivially by storing the values you got in the last hook call
[12:51] <marcoceppi> Okay, so I would have to implement it myself then, thanks! Didn't want to duplicate efforts
[12:52] <niemeyer> marcoceppi: Yeah, we thought for a while about how we might do this, but in the end it feels like the simplicity of the current approach is worth the extra trouble in the cases something like this is interesting
[12:52] <niemeyer> marcoceppi: There is also the possibility that the configuration will change _twice_ before config-changed is called
[12:53] <marcoceppi> I don't think it's really important for the majority of cases
[12:53] <niemeyer> marcoceppi: So it would not be honest if we promised to give you _the last value_
[12:53] <marcoceppi> Right
[12:55] <niemeyer> rog: "error" <3
[12:55] <rog> niemeyer: great innit?
[12:55] <niemeyer> rog: Totally
[12:56] <rog> niemeyer: reviewing those gocheck changes by any chance?
[12:56] <niemeyer> rog: If that's not bothering you right now, I'd like to keep focused on this stuff
[12:56] <rog> niemeyer: that's fine
[12:56] <niemeyer> rog: Actually, the gocheck ones might see a review sooner
[12:57] <niemeyer> rog: Since I'll need them too
[12:57] <rog> niemeyer: that's the only significant one
[12:57] <niemeyer> rog: Super
[12:57] <rog> the others are just gofix + a few minors
[12:57] <niemeyer> Cool
[12:57] <niemeyer> Let me do that now
[12:57] <niemeyer> Actually, let me reboot to sync a kernel upgrade
[12:58] <niemeyer> brb
[13:03] <hazmat> new aws region this morning
[13:04] <rog> niemeyer: what's the best way to cope with the fact that actual ec2 tests need private keys that we don't want to give to everyone?
[13:05] <niemeyer> rog: As far as the provider test stuff we've been discussing goes, the first batch of tests is actually unity rather than integrational
[13:05] <niemeyer> rog: So you can put anything as a pair
[13:05] <niemeyer> rog: We just need to ensure the signature matches
[13:06] <rog> niemeyer: i'm not sure i know what you mean by "unity". do you mean that we won't actually talk to ec2 itself?
[13:06] <niemeyer> rog: Yes
[13:06] <niemeyer> rog: None of the unit tests in juju talk to the real services
[13:06] <rog> niemeyer: but i want to check that my code actually works with ec2 before writing the other tests!
[13:07] <niemeyer> rog: You can have a set of tests which is integrational as well.. that'd be nice
[13:07] <niemeyer> rog: But not enough by itself
[13:07] <rog> niemeyer: necessary, i think, but not sufficient. i could just use env vars for the keys
[13:07] <niemeyer> rog: If you want to have integration tests in _addition_ to the unit tests, check out goamz
[13:08] <rog> niemeyer: i definitely want both.
[13:08] <niemeyer> rog: The basic trick is that there's a suite of tests that disables itself unless "-i" is passed to the runner
[13:08]  * hazmat is excited about unified provider testing
[13:08]  * rog is glad about that
[13:08] <niemeyer> rog: That's done by calling c.Skip("<the reason>") in SetUpSuite
[13:09] <rog> niemeyer: ah, i have seen that, but forgotten about it. what does ec2 do about the private keys?
[13:09] <rog> i mean the ec2 package
[13:09] <niemeyer> rog: Check goamz.. it has an authenticator that uses the standard EC2 env keys
[13:10] <rog> niemeyer: cool, so as i thought. makes sense.
[13:28] <niemeyer> rog: Any other changes outside of the checkers that are not related to os.Error?
[13:28]  * rog thinks
[13:28] <rog> i don't think so
[13:28] <rog> niemeyer: ^
[13:29] <niemeyer> rog: Cool, posting the review
[13:29] <niemeyer> rog: Great stuff
[13:29] <rog> niemeyer: cool
[13:29] <niemeyer> rog: Sent
[13:31] <rog> "POP3 checked too recently". dammit, i clicked refresh too early!
[13:33] <niemeyer> rog: WTF? gmail?
[13:33] <rog> niemeyer: yeah
[13:33] <rog> niemeyer: it's ok now - i think it enforces a minute or so's delay
[13:34] <niemeyer> rog: Yeah, I can see that being a good option.. if people check POP3 the same way they press lift buttons, it'd crash gmail quickly
[13:35] <rog> niemeyer: :-)
[13:41]  * rog wonders if panic(nil) is the same as runtime.Goexit()
[13:51] <niemeyer> rog: They have pretty different semantics
[13:51] <niemeyer> rog: panic(nil) is just that
[13:51] <rog> niemeyer: yeah they do. but it's not possible to tell which is which in a recover...
[13:53] <rog> niemeyer: i guess we just have to hope that noone calls Goexit inside a PanicMatches checker
[13:55] <niemeyer> rog: What would happen in that case?
[13:55] <rog> niemeyer: i'll just check
[13:55] <niemeyer> rog: It should simply say that the error is nil
[13:55] <niemeyer> rog: Or rather, the recovered value
[13:55] <rog> niemeyer: yeah, but the caller won't get the value
[13:56] <rog> that is returned
[13:56] <niemeyer> rog: Which will likely not match the defined expectation, and the test will fail nicely
[13:56] <rog> it just executes defers
[13:56] <rog> if you're doing it in the same thread, the test will finish
[13:56] <niemeyer> rog: Cool.. no worries
[13:57] <niemeyer> rog: We can think about that latter.. I'm happy to say "Don't do it" for now
[13:57] <rog> niemeyer: yeah, i don't think it's a problem in practice - it's just interesting
[13:57] <niemeyer> rog: Agreed
[13:58] <rog> niemeyer: BTW, what are "fixtures"?
[13:58] <niemeyer> rog: It's a fancy well known term for the setup/teardown in a test suite
[13:59] <rog> niemeyer: ah. not well known to me!
[13:59] <niemeyer> rog: http://en.wikipedia.org/wiki/Test_fixture
[14:00] <rog> should just've googled it!
[14:00] <niemeyer> rog: Sorry, it's certainly fine not to know it.. I just meant to say I wasn't inventing it
[14:01] <rog> niemeyer: sure. i just saw this name used all over the place with no mention in the docs, and it wasn't obvious to me what it referred to...
[14:13] <rog> niemeyer: is it deliberate that gocheck/printer_test.go isn't gofmted ?
[14:14] <rog> [i've never encountered a test before which fails if the test code isn't formatted right :-])
[14:14] <niemeyer> rog: It is
[14:14] <niemeyer> rog: Precisely because it's testing printing aspects
[14:14] <rog> niemeyer: darn, i just mucked it up by doing gofmt on it then
[14:14] <niemeyer> rog: Just revert it
[14:15] <niemeyer> rog: There may be a wiser way to test it, but let's not mix the issues
[14:15] <rog> sure. it just confused me for a bit...
[14:15] <rog> i'll put a comment in
[14:18] <rog> niemeyer: could we gofmt everything except printTestFunc ?
[14:19] <rog> (in another change, of course)
[14:21] <niemeyer> rog: Yeah, I suspect so.. run the tests and you'll be sure :)
[14:21] <rog> niemeyer: well, i've submitted the changes (not including that one)
[14:51] <niemeyer> rog: It's in
[14:51] <rog> niemeyer: cool
[14:51] <niemeyer> rog: Thanks again
[15:00]  * niemeyer => lunch
[15:26] <bloodearnest> heya juju-ers
[15:27] <bloodearnest> I may be missing something obvious, but how do I configure a openstack provider (specifically canonistack)?
[15:27] <bloodearnest> as opposes to an ec2 provider?
[15:41] <_mup_> Bug #888118 was filed: fixes for new error interface <juju:In Progress by rogpeppe> < https://launchpad.net/bugs/888118 >
[15:45] <_mup_> Bug #888119 was filed: fixes for new error interface <juju:In Progress by rogpeppe> < https://launchpad.net/bugs/888119 >
[15:47] <niemeyer> bloodearnest: Hey Simon
[15:47] <niemeyer> bloodearnest: Let me paste you a link, hold on
[15:47] <bloodearnest> niemeyer: thx
[15:48] <niemeyer> bloodearnest: https://pastebin.canonical.com/55366/
[15:49] <niemeyer> bloodearnest: This is Kapil's email explaining how to setup the internal Canonical openstack provider
[15:49] <niemeyer> (sorry to everybody else, it's just the provider config for Canonical's OpenStack, so not really interesting)
[15:50] <bloodearnest> niemeyer: great, thanks
[16:18] <hazmat> bloodearnest, ostack needs diable, but effectively its just the same ec2 provider with additional config
[16:18] <hazmat> er.. needs the diablo release
[16:18] <hazmat> or newer
[16:19] <bloodearnest> hazmat, diablo is what is in the juju/pkgs ppa for oneiric?
[16:20] <hazmat> bloodearnest, its a question of what version of openstack your running juju against, not the juju version
[16:20] <hazmat> the version in oneiric or the ppas both work fine against the latest openstack release
[16:20] <bloodearnest> hazmat: gotcha
[16:20] <hazmat> which is also in oneiric (latest ostack release)
[16:26]  * hazmat lunches
[16:50] <niemeyer> rog: http://paste.ubuntu.com/733258/
[16:51] <niemeyer> rog: Otherwise we get stuff like this: http://paste.ubuntu.com/733261/
[16:51] <rog> niemeyer: good point.
[16:51] <rog> niemeyer: shall i push a change?
[16:52] <niemeyer> rog: With the change we have this: http://paste.ubuntu.com/733264/
[16:52] <niemeyer> rog: Not necessary, if you're fine with it I'll commit
[16:53] <rog> niemeyer: LGTM. we're concerned about the string value, after all.
[16:53] <niemeyer> rog: Right, cool
[17:33] <_mup_> txzookeeper/session-and-conn-fail r65 committed by kapil.foss@gmail.com
[17:33] <_mup_> additional assertion msg on value of test env variable for deb installation of zk
[18:06] <hazmat> niemeyer, btw the wtf ftests seemed to have stalled out a few revs ago
[18:06] <hazmat> 404 vs trunk 411
[18:08] <niemeyer> hazmat: Will have a look at it
[18:08] <niemeyer> hazmat: I hadn't checked last time you mentioned, sorry
[18:09] <hazmat> niemeyer, no worries, we've all been busy and traveling
[18:15] <_mup_> txzookeeper/trunk r44 committed by kapil.foss@gmail.com
[18:15] <_mup_>  - On session expiration, all extant watches recieve an errback.
[18:15] <_mup_>    The watches are dead, so there is no purpose in having the session
[18:15] <_mup_>    error handler diverting errors for them.
[18:15] <_mup_>  - A retry client facade, that transparently retries operations in the
[18:15] <_mup_>    face of transient connection errors.
[18:15] <_mup_>  - A retry function in the style maybedeferred that can perform this
[18:15] <_mup_>    retry functionality for an arbitrary function.
[18:15] <_mup_>  - A series of connection failure tests verifying watches are
[18:15] <_mup_>    delivered to clients that where disconnected at the time of the
[18:15] <_mup_>    watched modification on the server.
[18:15] <_mup_>  - version increment to 0.9.0
[18:21] <hazmat> bcsaller, jimbaker could either of you have a look at lp:~fwereade/juju/clear-ks-meta  its been blocking a few other branches in the queue that are approved
[18:22] <bcsaller> hazmat: on it
[18:22] <hazmat> bcsaller, thanks
[18:23] <jimbaker> bcsaller, sounds good, we can have 3 reviews :)
[18:38]  * hazmat wonders how much spam mail is for deceased folks