[00:01] thumper: can you join #juju on canonical ? [00:01] need to talk about some stuff [00:02] thumper: oh wait, i'm not in #juju [00:02] use #eco [00:34] davecheney: hi, doctor running late as usual. i've fixed william's issues with by bootstrap branch but wanted to understand your issues. i can't really see what the problem is. so long as tools are uploaded to public buckets when ppa is released, things just work. and stricter matching is only done on major.minor, so point releases can still be used [00:35] wallyworld__: when you say "public bucket" that only works for ec2 [00:35] private openstack clouds act as if they have no tools an fall back to using s3 for _release_ (not devel) tools only [00:36] your change would prevent them accepting the final fallback toolset and their bootstrap will fail [00:36] i 100% agree that mixing toolsets is a mistake [00:36] but that genie is out of the bottle and people are using it now [00:39] davecheney: i just got called in, will catch up in a bit [01:24] bigjools: would you mind landing my gwacl branch? pretty sure I don't have rights to [01:24] davecheney: you weren't there [01:24] davecheney: was at the gym, sorry [01:24] axw: ah, I can fix that [01:26] axw: land away! :) [01:26] thumper: imma there [01:26] #eco on canonical [01:26] oh [01:26] bigjools: thanks. next question: how? :) I haven't landed without lbox before [01:27] axw: just change the status of the MP to "approved" and the bot does the rest [01:27] * bigjools grumbles about lbox [01:27] bigjools: ah right, just didn't show up before cos I wasn't in the group. of course. [01:27] thanks! [01:28] yup [01:50] thumper: i might even bring forward 1.13.3 tagging to today [01:50] if I can do the upgrade testing [01:50] 'cos wallyworld wants to break everything [01:50] (wallyworld is sans internets, he'll be here soon) [01:53] axw: my gwacl bot seems to be dead... fixing [01:53] bigjools: thanks [01:53] axw: ah it's not [01:53] did you set a commit message? [01:54] I think so... checking [01:54] nope [01:54] dah [01:54] thanks [01:54] fixed [01:54] tarmac silently ignores MPs with no commit msg [01:54] bot runs every ten minutes [01:55] I need to get landing moved over to the one that jam runs [01:55] okey dokey, thanks bigjools [02:00] davecheney: is this wallyworld's tool selection work? [02:00] wot [02:00] hi wallyworld [02:00] hey [02:00] wallyworld: davecheney says you want to break the wold [02:00] world [02:00] well, not really [02:01] only for private clouds that choose not to set up a public bucket for tools [02:01] wallyworld: lp:~axwalk/juju-core/juju-metadata-generate-tools [02:01] and rely on sync tools pulling down possibly outdated tools from s3 [02:01] wallyworld: so how is it breaking? [02:02] now, juju will fall back to using any tools where the major version number matches [02:02] eg 1.3 client will use 1.2 tools [02:02] but the change now restricts the matching to require major.minor match [02:03] patch updates are used though [02:03] so 1.3.0 client will use 1.3.2 tools [02:03] I don't think that is reasonable [02:04] william does [02:04] I'd say only use patch updates for non-dev releases [02:04] we break things from point release to point release on dev envs [02:05] we can't guarantee 1.28 will be compatible with 1.26 [02:05] it's not an issue in practice [02:06] juju release = upload tools and then upload ppa [02:06] so there are always tools [02:07] for devs on release+1, they should be using --upload-tools [02:08] thumper: william is the one driving this change [02:08] sure [02:08] I guess that's fine [02:08] i'm +0 on it - i can see pros and cons [02:13] wallyworld: correction, juju release uploads tools for *known* cloulds, the CPC clouds [02:13] there exists an unknown set of non public clouds [02:15] who currently (inadvertendtly) rely on the automatic sync-tools behavior that bootstrap does for them [02:15] i 100% agree this is wrong and bad [02:15] but if we take it away from them, they'll lynch us [03:20] wallyworld: I suggest we skip the package review stuff with axw as you are sprinting [03:20] thumper: sounds good to me [03:20] wallyworld: please let axw know [03:20] will do [05:50] 15:48 error: invalid value "maas-name=mongodb.lab.boston.cts.canonical.com" for flag --constraints: unknown constraint "maas-name" [05:50] ^ i think i already know the answer [05:50] but what do I tell jpds ? [06:07] bigjools: can you response please [06:07] davecheney: OTP [06:07] bigjools: when you are free [06:08] but looks like a juju error [06:08] and juju-core doesn't support maas flags [06:09] oh cock [06:09] yes James [06:09] thumper: bigjools: i got my coffee machine back! :-D [06:09] \o/ [06:09] * jtv cheers for wallyworld_ [06:09] it's heating up right now :-D [06:09] and I ran out of beans [06:10] Go over to wallyworld_'s right now — I hear he has working equipment [06:10] I heard the cord was cut [06:10] * wallyworld_ is the coffee nazi - no beans for you [06:11] boom bomm ching [06:11] davecheney: wtf is "maas-name" anyway? [06:11] bigjools: constraints the units to the maas tag [06:11] that's maas-tag I thought [06:11] maas-tags even [06:11] https://juju.ubuntu.com/docs/charms-constraints.html [06:11] and only on pyjuju [06:11] docs says maas-name [06:12] maas docs say maas-tags.... [06:12] haha [06:12] is he using juju-core or pyjuju? [06:12] * davecheney starts to cry [06:12] juju-core [06:12] he's fucked then [06:13] how charming [06:13] until fwereade_ gets provider-specific constraints in (I think --to was being talked about) [06:13] he's not going to be charming [06:15] jpds: short version, we haven't implemented provider specific constriants yet [06:15] the docs are wrong [06:15] they probably refer to pyjuju [06:15] bigjools: That did exist in pyjuju. [06:16] exactly [06:27] jpds: fwiw, https://bugs.launchpad.net/juju-core/+bug/1170337 [06:27] <_mup_> Bug #1170337: maas provider: missing support for maas-specific constraints

[06:27] also, https://bugs.launchpad.net/juju-core/+bug/1170337 [06:27] <_mup_> Bug #1170337: maas provider: missing support for maas-specific constraints

[06:27] shit [06:28] Keep calm. [06:28] https://bugs.launchpad.net/juju-core/+bug/1217717 [06:28] <_mup_> Bug #1217717: docs: charm constraints page refers to unsupported 'maas-name' constraint [06:37] axw: did we get gwacl updated on the build bot to match your "critical update gwacl" patch? [06:37] the bot doesn't (yet) actually look at dependency.tsv [06:37] jam: no, but it doesn't affect the juju-core tests (it's tested in gwacl) [06:38] axw: sure, but we probably actually want the bot to be building with the version of gwacl we are suggesting. I'll go update it. [06:38] (It also helps that if there was an accidental incompatibility break we would notice it.) [06:38] jam: fair enough, thank you === tasdomas_afk is now known as tasdomas [07:09] Guys, my bootstrap node is dying. [07:10] /var/log/juju/machine-0.log keeps aying: juju environ.go:37 worker: loaded invalid environment configuration: maas-oauth: expected string, got nothing [07:11] Which is a lie. [07:19] jpds, do you know the juju version you used to bootstrap, and the jujud version you're runnning? [07:20] fwereade_: Good morning. I'm slightly concerned that we really do have a bug we need to deal with in ServiceGet. Specifically, the charm config types are described in the schema (description, type, value), and on the server side we are doing the work to put the data into the right type. But we lose that type when we transmit it via JSON. [07:20] fwereade_: ppa:juju/devel 1.13.2. [07:21] fwereade_: so do we need to implement a pass over the data in the client side of ServiceGet? [07:22] fwereade_: But yeah, I've just bootstrap'ed it and nothing works, not even status. [07:25] jpds, would you find the jujud on the bootstrap node (/var/lib/juju/tools/machine-0?) and run `jujud version`, just to check, please [07:25] jam, blech [07:27] fwereade_: 1.13.2-precise-amd64 [07:28] jpds, hmm, would you pastebin me /var/log/cloud-init-output.log please? [07:28] mornin' all [07:28] jam: can you give a specific case when it would be a problem? [07:29] jam, I can accept that's a bug, but I'm reluctant to fix ServiceGet which itself is pretty insane [07:29] rogpeppe: The fact that the metadata tells you what type you have, and the existing code spends the effort to return things of that type sound like the code has made some expectations. [07:30] jam, ISTM that it's an unholy combination of service info and charm info, and that there is literally no possible justification for smooshing that information into the same API call [07:30] fwereade_: +1 [07:30] jam, if we didn't do that mixing, the only problem would be precision, right? [07:31] fwereade_: well, some code may rely on the fact that we expect an int64 for an int attribute value [07:31] fwereade_: so I can confirm the precision issue (I added a test that proves it). The other issue is that you could easily write code that does "var stuff int64 = result.Config["skill-level"]["value"]" [07:31] jam: but i'd still like to see at least one place where this is actually a problem [07:31] rogpeppe: the main problem is that it is code that *we* didn't write. [07:32] jam: ah, you're worrying about 3rd party code using the API? [07:32] rogpeppe: I'm concerned that we have code that clearly spent a lot of time to get types right that we are throwing away [07:33] fwereade_, rogpeppe: I'm willing to just push it forward, file a bug and get on with life, but it was clearly some effort into doing it the way it is done today. [07:33] fwereade_: /msg. [07:33] jam: when we could represent integers in the marshalled form of the data, it made sense to represent an int as an int [07:34] jam: but given that we're now using JSON, i don't see that is necessary. [07:34] rogpeppe, I thought we *could* represent ints regardless [07:34] rogpeppe, jam, I'm starting to be convinced here [07:36] fwereade_: we *could* but it's awkward to do [07:36] rogpeppe, jam, although I still sorta lean towards a "ServiceGet is hopeless rubbish, but it's not just ServiceGet we need to worry about, we should actually fix our marshalling" [07:36] fwereade_: what's bad about ServiceGet, for the record? [07:36] rogpeppe, we've already encountered this problem in environment config [07:37] rogpeppe, it's mixing together charm stuff and service stuff for no clear reason [07:37] rogpeppe: the specific bad of ServiceGet is that it mixes the Charm.Config object with the Service.Constraints data [07:37] which should really be 2 different calls. [07:38] fwereade_, rogpeppe: bug #1217742, I'll document it in the code and reference that bug if we find it is really important to fix. [07:38] <_mup_> Bug #1217742: ServiceGet returns integer values as float64 [07:38] fwereade_: most of our marshalling uses "structs" that will enforce types [07:38] ServiceGet is a bit special in that it is passing around user-data that is in a map[string]interface{} [07:39] fwereade_: i don't really mind the fact that it's one call where it could be two, if most API usage gets both things at the same time [07:39] fwereade_: i'm not sure it makes it hopeless rubbish [07:39] jam: yeah [07:39] jam, I'm not so bothered about service config vs constraints, getting and (beinga ble to) set all service info at once is fine by me really... the big problem is total asymetry [07:40] jam: i'm trying to think of other places that pass around a free interface{} [07:40] jam: we could potentially just use UseNumber always [07:41] rogpeppe, jam: we had that problem with ports in env config [07:41] hmm, why does Resolved return settings? [07:41] rogpeppe, jam, we will probably have it again when unit agents need to use service config [07:41] rogpeppe: we could change it to UseNumber, but we'd still need to implement the custom unmarshalling in ServiceGet to cast the Number into the correct types. [07:42] rogpeppe, I have *no* freaking idea [07:42] rogpeppe, because it seemed like a good idea at the time, regardless of layering/sanity concerns [07:42] rogpeppe, just like ServiceGet ;p [07:42] fwereade_: ports aren't in typed structs? [07:42] I guess EnvironConfig isn't type [07:42] typed [07:42] jam, environment config resists that sort of thing pretty hard [07:43] jam: we could just document that the Go API has changed [07:43] fwereade_: i was looking over some of the camlistore source at the weekend, and it's interesting to see how it manages configuration stuff. it's got quite a neat little type to manage it. [07:44] rogpeppe, oh yes? [07:45] fwereade_: http://godoc.org/github.com/bradfitz/camlistore/pkg/jsonconfig [07:45] * jam goes to grab lunch, will be back soon. [07:46] fwereade_: the cunning bit is Validate [07:46] fwereade_: in particular, lookForUnknownKeys works out which keys could be in the config by knowing what keys have been looked up previously [07:47] fwereade_: which is actually kinda neat if you think about it [07:47] fwereade_: i'm not that keen on the way it stores extra keys in the map though. [07:49] fwereade_: anyway, interesting to see how other code deals with similar issues. [07:49] rogpeppe, thanks, I'll try to take a proper look shortly :) [07:53] a review of this would be much appreciated please. it's large but it's just moving code. https://codereview.appspot.com/13269045/ [07:58] jam, rogpeppe, I have a theory for why jpds's environment is broken [07:59] fwereade_: oh yes? [07:59] jam, rogpeppe: the upgrader api is trying to look in the environment for tools before we've sent the environ config secrets over [08:00] jam, rogpeppe: and for bonus points ServerError is panicking because schema.error_ is unhashable and can't be used with ServerError [08:01] fwereade_: hmm, the upgrader used to wait until it had got a valid environment config [08:02] fwereade_: i guess things will probably sort themselves out eventually [08:02] jam, rogpeppe: leaving aside that it should *never* have had access to an environ config, yes ;p [08:02] rogpeppe, not sure it is actually doing so [08:02] fwereade_: well, sure [08:03] rogpeppe: I have a 43MB log file with a time range of 30 minutes - full of tracebacks. :) [08:03] jpds, how does juju status fail exactly? [08:03] fwereade_: It didn't return. [08:04] I just bootstrap'ed, it installed and immediately started freaking out. [08:04] jpds: could you paste a representative example of some of the log file (including at least two iterations of the traceback)? [08:05] rogpeppe: They're on https://chinstrap.canonical.com/~jpds/juju-debug/ [08:05] jpds, is it remotely possible that you killed the status before mongod was running on the server, and haven't run it since? [08:05] jpds: perhaps from the very start up until it starts to look repetititive [08:05] rogpeppe: The full all-machines.log is there. [08:05] fwereade_: you made a comment on my last CL regarding the GUI team. whom can i ask for it best? [08:06] fwereade_: I may have Ctrl-C'ed it - I remember I ran status before the machine came up.. [08:06] jpds, would you try juju status again please? [08:07] jpds, when that can connect to mongo, the first thing it'll do is hand over any missing secrets [08:07] hmm, this looks highly suspicious: "panic: runtime error: hash of unhashable type schema.error_" [08:07] jpds, this is still definitely a bug, but it might be easily resolved that way [08:07] rogpeppe, yeah, that was what led me in that direction [08:08] rogpeppe, regardless of tools returning an error, that nukes the whole process [08:08] rogpeppe, if ServerError didn't panic, I think the upgrader would nicely fail and get retried [08:08] fwereade_: The status is just sitting there and the log is just getting more errors. [08:08] rogpeppe, oh except, wait, we're still using allFatal for some reason [08:09] jpds, would you run it with --debug and see if anything interesting pops up? [08:09] fwereade_: 2013-08-28 08:09:28 INFO juju.state open.go:68 opening state; mongo addresses: ["angha.maas:37017"]; entity "" [08:09] And nothing. [08:10] Log continues to complain about: maas-oauth: expected string, got nothing [08:10] fwereade_: hmm, schema should really return an error that's a pointer type [08:11] 678646 [08:11] rogpeppe, maybe so, but ServerError should also not be assuming that something's hashable just because it implements error [08:11] good thing those are one-time passwords :) [08:11] fwereade_: that is true too [08:11] jam, haha [08:12] fwereade_: that's my fault entirely. [08:12] fwereade_: though I guess if you give away 2 of them, you can figure out the sequence, or something along those lines (given setting one up is start it, sync it, and enter 2 sequential values) [08:12] rogpeppe, not to worry, we can fix it [08:12] rogpeppe: we should probably be decreasing "discarding action method" from INFO to at least DEBUG, fwiw [08:13] jpds, can you definitely resolve angha.maas from where you're running? [08:14] jam: i have an old branch somewhere that would let us discard that message entirely [08:14] jam: at the least it could only log exported methods, because they're the ones where problems are likely to lie [08:14] fwereade_: Oh, that's interesting; fixed DNS and now it works. [08:14] jpds, because it's starting to look like that's the underlying problem -- the environ errors are an expected consequence of no-secrets-yet, and the panics are an unexpected one, but both will be sorted out once we hand over the secrets [08:14] jpds, sweet [08:15] And the server looks happier. [08:15] rogpeppe, fwereade_: so one thing we certainly want to fix, is ServerError(unknownError) shouldn't ever panic. How do we detect that a type is unhashable and can't be looked up in a map? [08:15] jpds, secrets handover happens first time you connect to an environment [08:15] I wouldn't normally expect it to fail like that on DNS though... [08:15] fwereade_: I see. [08:15] jam: i think we could probably use a switch instead. [08:16] jam: alternatively we could recover from it [08:16] rogpeppe, *is* there a way to detect it other than to try, panic, recover? [08:16] fwereade_: perhaps with reflect [08:16] rogpeppe, eww ;p [08:17] Maybe the node should just sit there until status is run? It's kind of failing up with log files otherwise... [08:18] fwereade_: actually i can't see an easy way even with reflect [08:18] jpds, I think that if we fixed the ServerError panic things would look a lot better [08:18] jpds, panic tracebacks are very heavyweight [08:19] jpds, but there is indeed another bug to fix to prevent it just repeatedly erroring and trying again regardless [08:21] jam, rogpeppe: I think *that* one would be fixed by doing a WaitForEnviron in Upgrader.Tools [08:22] rogpeppe: would the ,ok syntax work, or it still panics on non-hashable types [08:23] jam, rogpeppe, jpds; I'd be a bit reluctant to make *everything* wait for bootstrap to complete [08:23] fwereade_: i'm not entirely sure about that [08:24] jam: the ,ok syntax would not work [08:24] jam, rogpeppe, jpds: better for just the things that need an environment to wait really [08:24] jam: but a switch would [08:24] sigh, my debug-log keeps filling up with "panic: runtime error: hash of unhashable type schema.error_" error still. [08:24] rogpeppe, jam, a switch seems sane to me, just dodge the whole issue [08:24] fwereade_: yeah [08:25] rogpeppe: we have a switch just after it, but I don't quite know what a switch for unhashable types would look like [08:25] My google-fu for "golang unhashable" isn't very helpful [08:25] jam, the point is just that a switch won't try to hash it [08:25] jam: comparing unhashable types is ok if they're different underlying types [08:26] jam: equality comparison compares the types first, then the value [08:26] * rogpeppe goes to makes sure of chapter and verse [08:26] rogpeppe: so it is *usually* a good idea to avoid hardcoding a switch/series of if/else statements if you can put that information into a map so that it is O(1) lookup instead of O(n) and usually maps are easier to add data to at runtime for types that you may not have known about yet. [08:27] So I'd still like to keep the "we have a map for registered types," that we can look in [08:27] jpds, that is... more upsettin [08:27] jpds, is the server still generating those panics after a successful status, or is debug-log itself screwy? [08:28] jpds, there was a bug with rsyslog resyncing state it didn't need to, and I think it was fixed, but I'm not sure when [08:28] wallyworld_, ^^ [08:28] fwereade_: I'm pretty sure that fix is in 1.13.2. You can confirm by checking /etc/rsyslogd/25-juju.log There should be a couple of lines with &~ inbetween them. [08:29] It fixed it in our testing at least. [08:29] And it only triggered when you had deployed a unit to machine-0 [08:29] and we haven't gotten to the point of deploying yet. [08:30] fwereade_: tail'ing the log on the bootstrap node to make sure debug-log isn't just playing catch up. [08:30] jpds, look at machine-0.log, that wouldn't demonstrate the problem even if it were still there [08:31] jam: i was thinking of something like this: http://paste.ubuntu.com/6035835/ [08:31] jam: but it will indeed be O(n) [08:31] fwereade_: ping [08:32] rogpeppe: and not extensible at runtime [08:32] jam: i think on balance i'm preferring the recovery approach [08:32] jam: is that something we'd want? [08:32] rogpeppe: that's where I'm getting to as well. [08:32] rogpeppe: it is often a nice pattern to be able to add things you didn't think about ahead of time as data rather than code. [08:32] jam: at runtime? [08:32] fwereade_: Yeah, that looks OK, it's just playing ping pong. [08:33] rogpeppe: it would allow packages that define an error to register that error mapping into a code [08:33] jpds, ok, cool [08:33] rogpeppe: then the places that define the error define their code [08:33] jam: they can do that anyway, by returning an error with a Code method [08:33] rather than having to have "common/errors.go" know about all possible errors. [08:34] jam: common/errors.go is really for legacy errors [08:34] jam: or at least, that was the intention [08:34] TheMue, pong [08:35] fwereade_: seen my question above regarding the GUI team? [08:35] jam: i guess it comes down to dependencies [08:35] fwereade_: whom can i ask best to be sure about the change? [08:36] TheMue, frankban seems to be right here and would be a good person [08:36] fwereade_: thanks [08:36] jam: and responsibility - we either have lots more things import state/api/params (for the error codes) or something has to be responsible for registering error types [08:36] rogpeppe: it is the Factory pattern which is often quite good, especially for mapping things of X to things of Y. It happens that go specifics mean it may not be great here. [08:36] TheMue, but if he weren't you could probably just pop into #juju-gui and see who's around ;) [08:37] fwereade_: oh, didn't know about that channel. then it's more easy ;) [08:37] fwereade_: after that i'll take a look at the ssl issue. here i may come back to you with questions. [08:37] How do I forcibly move a machien from dying to dead? (It was never alive and I didn't want it to be) - already terminate-machine'd it. [08:39] jam: i'm not quite sure how what you mean there [08:40] jpds, if it's dying, it should have 0 units, and the provisioner ought to clear it up for you... [08:40] jpds, but we did also see a bug in which the provisioner *sometimes* misses a machine that needs cleanup [08:40] jpds, so you may have encountered that [08:41] It's still "Allocated to root" in MAAS. [08:41] jpds, and in status it appears as dying, with an instance id? [08:42] fwereade_: Yes. [08:42] jpds, if the machine is still coming up you just have to wait for it to appear, and the machine agent will figure out that it's no longer wanted and remove itself [08:44] rogpeppe: ugh. we have no direct tests of common.ServerError, at least not in the common package. [08:44] jam: yeah, the test is in state/apiserver. it obviously wasn't moved over when we moved the code. [08:44] jpds, there's room for us to improve that story though [08:45] jpds, I imagine you wouldn't be mentioning it if it weren't annoying, so I'll write some bugs [08:45] jpds, thanks [08:46] fwereade_: Yeah, problem was the machine is a VM with no power settings, so it was never going to boot... [08:47] jpds, ha, I see [08:51] jam, fwereade_: https://codereview.appspot.com/13336043 [08:51] fwereade_: Let me know if you file bugs so I can track them. [08:52] rogpeppe, I'd prefer a code, ok sort of return really [08:53] rogpeppe, it seems a little bit magic [08:53] rogpeppe, and in-band signalling is just generally a Bad Thing ;) [08:54] fwereade_: you'd prefer something like this? http://paste.ubuntu.com/6035888/ [08:54] rogpeppe: for the opposite method I'm submitting it now [08:54] rogpeppe, yeah, I think so, if you have no objections [08:54] waiting for lbox to finish [08:55] rogpeppe, the magic doesn't feel painful now [08:55] fwereade_: ok, fair enough [08:55] rogpeppe: I traced back to who introduced the singleton error map, which is quite a while ago (rev 957 or so) [08:55] jam: i did that [08:55] and lbox fails with "failed to load data" [08:55] jam: it's all my fault :-) [08:56] jpds: bug #1217760 for the bad panic bug [08:56] <_mup_> Bug #1217760: apiserver.common.ServerError needs to handle unhashable errors [08:58] jam: Thanks. [08:59] rogpeppe: https://codereview.appspot.com/13338043 [08:59] hi noodles775 (/wave) [08:59] jam: o/ [09:00] rogpeppe: at this point, I don't *really* care which fix goes in, though we'll want to associate whatever lands with the bug # [09:01] jam, fwereade_: alternative updated: https://codereview.appspot.com/13336043 [09:02] jam, fwereade_: i don't mind much either, although i quite like the more compact nature of the switch. (and using recover in that kind of way has reasonable precedent) [09:03] s/switch/map lookup/ [09:05] jpds, https://bugs.launchpad.net/juju-core/+bug/1217781 [09:05] <_mup_> Bug #1217781: machine destruction depends on machine agents [09:05] rogpeppe: I like the map lookup, the fact that you have to recover tells me it is something to be scared of [09:05] *but* the fact [09:06] jam: for a similar kind of use, see http://golang.org/src/pkg/os/exec/exec.go?s=5901:5926#L122 [09:07] jam: i think it's reasonable [09:08] fwereade_: Ta. [09:08] rogpeppe: I defer to a 3rd party for final decision about the tastefulness of a defer() {recover()} it looks la lot like a "try: except:" in python which you should almost always universally avoid. [09:08] as it suppresses all errors. [09:08] jam: there's only one error possible there [09:08] such as fwereade_^^ [09:08] jam: your code could be a little more compact if you stored the singleton codes in a table and iterated over them [09:09] fwereade_: yeah, i defer to you too [09:09] rogpeppe: we have a switch today, might as well add some bits to it. [09:09] * rogpeppe likes tables [09:10] rogpeppe, jam, I was fine with a switch, but I thought we were leaning towards maps being nice? if we agree that maps are nice I'm fine with the recover [09:10] fwereade_: to be clear, we both have a solution to the problem and not enough motive to decide between, just pick one and we'll go about our lives in a merry fashion. https://codereview.appspot.com/13338043/ and https://codereview.appspot.com/13336043/ [09:10] fwereade_: map is nice, recover is ugly, etc. :) [09:11] jam, rogpeppe: rogpeppe wins by the highly scientific toss-a-coin method [09:11] lol [09:12] jam, rogpeppe: a bit annoying that euros don't have heads on them, that gave me pause for a moment [09:14] (jam, if I wanted to debate further, I'd contend that recover is more unfamiliar than intrinsically ugly, and that when the scope is so very narrow I don't see any problems with it) [09:16] rogpeppe, jam: separately [09:16] fwereade_: having to write a function to do a safe map lookup is... unfortunate. [09:16] rogpeppe: go for it [09:16] rogpeppe, jam: I contend that ca-private-key is Just Another Secret [09:17] rogpeppe, jam: and should be communicated just like all the other secrets [09:17] fwereade_: I take it this is a different discussion. [09:17] fwereade_: how can we do that? [09:17] fwereade_: we can't talk to the server over TLS until it has that secret [09:17] jam: exactly [09:17] rogpeppe, jam: *ca*-private-key [09:18]