[00:07] i'll be around for a while [00:07] thumper: no right now I'm not. I'm working on this mgo dup key issue [00:07] thumper: I can help if needed though [00:08] thumper: menn0 I'll be around for another 90 minutes or so [00:08] so no huge rush [00:08] redir: should I have a quick look at it with you now while you're still around? [00:09] menn0: if you are at a good stopping point sure. If not let me know when you get to one. [00:09] redir: now is good [00:10] redir: hangout or IRC? [00:10] HO [00:10] ? [00:10] ok, let's just use the tanzanite-standup one [00:10] redir: ^ [00:11] k [01:00] axw: do you have a moment for a quick chat? [01:00] wallyworld: sure [01:00] standup wil do [01:03] wallyworld: very hard to hear you [01:03] axw: i'll reconnect [01:45] redir: is that race sorted? [01:48] Bug #1604919 changed: juju-status stuck in pending on win2012hvr2 deployment

[02:11] menn0: https://github.com/reedobrien/mgo/tree/fix-race-in-stats [02:12] menn0: I can make a PR if you want. But if you think it needs more polish... go ahead. === natefinch-afk is now known as natefinch [02:12] menn0: same results on the tests with or without the patch. [02:14] thumper: ^^ [02:16] menn0: http://reviews.vapour.ws/r/5284/diff/# [02:16] menn0: I think you fixed the original, this is 1.25 now [02:16] axw: oh, you are oncall reviewer [02:17] axw: you could look above if you like [02:18] Bug #1458585 changed: SSHGoCryptoCommandSuite.TestCommand fails

[02:20] thumper: sure, looking [02:21] thumper: LGTM [02:21] axw: ta [02:24] axw,wallyworld: isn't status history updated outside of transactions? [02:25] so raw access? [02:25] thumper: I think so? [02:25] thumper: i thought so [02:25] allcollections doesn't mark it as rawAccess [02:25] I'm looking at the bug about big transactions to clean up [02:26] * thumper looks [02:26] maybe the collection is accessed directly without txn ops [02:26] it is accessed without txn ops [02:26] or was last time I looked [02:26] st.getRawCollection(statusesHistoryC) [02:27] hmm... we probably want to mark it as so otherwise removing the items uses transactions :) [02:27] I'll do it [02:31] thumper: sorry, was lunching... looking [02:33] thumper: looks good, although I don't think I fixed this in master (at least I don't remember doing it) [02:34] I compared the patch with the utils package [02:34] menn0: axw has reviewed anyway [02:36] Is add-cloud intended to work with the static clouds, for example, ec2? (it does, I just am wondering if it's *supposed to*) [02:38] natefinch: it is supposed to allow you to add your own config [02:38] thumper: so getRawCollection() - does that not work if collection is not marked as raw? [02:38] thst sorta sucks a bit [02:38] wallyworld: it does [02:39] wallyworld: ok, I had assumed it was only for things like manual, openstack, and maas, where you can actually create your own cloud [02:39] wallyworld: but we have code that iterate over the all collections [02:39] and do different things for raw [02:39] ah ok [02:39] natefinch: private cloud set up is one use case for sure [02:40] wallyworld: just wondering, since I'm working on the interactive add-cloud [02:41] do the private cloud first, and then the public cloud config stuff can be done later - i'm prerry sure the doc references it [02:41] one issue is that we need to enumerate valid config items to make user input sensible [02:41] and there's not really a clear path to do that yet [02:43] wallyworld: yeah... right now I'm just hard-coding it per cloud. [02:44] the valid config items? [02:44] wallyworld: what values to ask the user for (which map to config values) [02:44] we should be able to use the config schema definition [02:44] just as is done when parsing config.yaml [02:45] but use it to get at the valid item names and types [02:46] I'm not sure I can use the schema to make a user-friendly UI. [02:47] really? it has the attribute names, their types, whether they are mandatory etc [02:47] what might be a good compromise is to put the interactive add-cloud code inside each provider, so it lives with the code that knows what values to ask about. [02:48] wallyworld: the key word there is user-friendly [02:48] how else would it be done if not using the schema? [02:48] wallyworld: by having a human write sentences that humans can understand [02:48] huh? for name - value input? [02:49] wallyworld: this is for the interactive add-cloud. I'm not going to just prompt them with the yaml field names. [02:50] that's what is used now in config.yaml files, and on the CLI as --config args [02:50] yes, and it's awful, and that's why we're writing an interactive mode. [02:50] what's wrong with allowing them to enter a value for "http-proxy" say [02:51] that is entirely readable [02:51] you'd use tab completion to help too [02:51] and print the description of each field also [02:55] because if we write it by hand, it'll be clean, crisp, and tasteful. If we auto-generate it, it'll feel auto-generated, it won't be able to do intelligent verification (like checking that a URL is a valid URL)... [02:57] why can't we check a valid url? of course we can [02:58] the schema doesn't say it's a url, it just says it's a string.... I'm sure we check it later on sometime, but it's one of those things where you'll enter 10 fields, then it'll go off and run through a verification, and spit back that field #7 is incorrect [02:58] whether it is done off a schema or we hard code prompts, the UX is the same [02:59] I guarantee you, the UX will not be the same if it's hand coded. [02:59] the schema does need to say it's a url, yes. we can do that [02:59] That's just one example [02:59] why won't it be the same? [02:59] it's printing a prompt to enter a value [02:59] in either case [03:00] yes, but the prompt is quite likely not to be exactly the same as the description of the yaml field [03:00] so we fix our metadata [03:00] also, there's intelligence that is outside the schema... like the fact that openstack username and password only apply if the auth-mode is user-pass [03:00] how do we handle the case where the config schema gains a new value? [03:01] we have already talked about the need to make the schema support grouping and conditional fields [03:01] making the schema more complicated is not the answer [03:01] it's ok to write code [03:02] it's not ok to create something that is hard to maintain [03:02] and prone to skew [03:02] schemas are the common solution for user data entry. our gui uses json schema for example [03:04] we'll spend days, weeks, adding gobs of complexity to the schema just to avoid the simplest of imperative code. [03:05] it's not gobs of complexity [03:05] every time we have to do an if/else... that's significant added complexity and cognitive overhead to the schema... when it's completely trivial in imperative code. [03:06] how do you signify that openstack user and password only apply if auth-mode is userpass? [03:06] using a directive in the schema - that's what schemas are for [03:06] how do you do it? [03:07] http://stackoverflow.com/questions/9029524/json-schema-specify-field-is-required-based-on-value-of-another-field [03:07] * thumper taps his fingers while the state tests run [03:07] perhaps I should go and clean the coffee machine [03:07] i haven't got the definitive refence handy [03:08] but we are talking about bog standard schema features [03:09] oh ffs [03:09] state tests take over 10 minutes [03:09] that's jsonschema... the provider config schema is our own custom thing, isn't it? gopkg.in/juju/environschema.v1 [03:09] if we hard code it, who will take the lead on ensuring any config additon or change to the schema will be reflected in add-cloud? that sort of double handing and non-DRY leads to bugs [03:10] time go test -check.v -test.timeout=1200s -cover [03:10] yes it is our own, but trivial to enhance [03:10] lets see what that shows us [03:10] now I'm definitely going to clean the coffee machine [03:11] wallyworld: I was actually thinking that the interactive code for each provider should live in the provider. Then it lives right next to the configuration, and so it's easy to check that any changes to the config have corresponding changes in the interactive code. [03:11] but a lot of the base config is defined outisde of the provider in environs/config [03:14] sure, if and when we decide to automate those parts, the common interactive bits for those parts can live next to the common config definitions. The other nice thing about just writing code is that it's easy to pick a sensible subset of things to ask the user, rather than giving them 50 prompts, when 48 of those are optional. [03:16] the optional schema attributes would not be prompted for - the code can use the is-optional property of the schema to drive that [03:20] we're getting down a rat hole. My initial statement is still the same. We'll have to add a ton of complexity to our schemas (and I *do not* believe that adding conditional dependencies to our schema is a small amount of work), all to save a very small and easily maintained bit of code. And every time we have some other custom field that works in some custom way, we'll have to extend our schema in new and interesting ways and it'll becomes a [03:20] maintenance burden of its own. Also to avoid writing self-contained, very simple imperative code that lives near the configuration values it is intended to fill. [03:20] s/Also/All [03:21] i disagree, as do every other project that uses a schemma to drive user input [03:21] coverage: 85.3% of statements [03:21] ok github.com/juju/juju/state 617.074s [03:21] real 11m3.809s [03:24] wallyworld: you can generate a functional UI, you can't generate a *good* one. And I bet I can write all the UIs for all our private clouds in less time than I could write the update to our schema to just support openstack. [03:25] sure, but at the cost of maintability. it's always easy to bang out bespoke code [03:26] openstack and aws both have different credential types [03:26] axw: http://reviews.vapour.ws/r/5285/ [03:27] it's not complicated code. Print "What auth mode would you like (options..): if authmode == openstack.userpass { Print "What username?" } etc. [03:28] and that can be trivially driven by a schema [03:28] to produce the exact same output [03:29] but will be maintainable [03:30] I already find our usage of schemas to be hard to understand.... adding more complexity is just going to make that worse. [03:32] to be fair, I think that has less to do with the schema itself and more our usage of it [03:32] seems like you are conflating a schema driven approach with not understanding our schema [03:34] well, no. [03:34] thumper: reviewed [03:41] wallyworld: I'm trying to avoid writing a framework, and just write what we need. Do the simplest thing that could possibly work. If I'm some newbie juju dev, and I add a config value to some provider, and it needs some custom logic in the prompt, it's trivial to just write that code. If instead I have to go try to figure out how to bend the schema to work, or, more likely, add logic to the schema, it's going to take me an order of magnitude [03:41] longer. We haven't even started and we've already mentioned two additions we would have to make for the schema. [03:43] we can disagree :-) [03:44] sure, but we gotta pick one :) [03:44] natefinch: the reason for using a schema is because you may not have acccess to the provider code at all times [03:45] natefinch: e.g. the GUI, or an older juju client [03:50] well, the older client wouldn't have the new provider code anyway, so it wouldn't know what to do with the information even if it could request it. [03:51] natefinch: why not? the client doesn't talk to the cloud directly, except for when it's bootstrapping or destroying the controller [03:53] natefinch: sorry, you're specifically looking at bootstrap aren't you. credentials are bigger than just bootstrap [03:53] axw: currently looking at add-cloud [03:53] natefinch: it should be possible to add credentials for a cloud after bootstrap also [03:55] axw: removed the retry, and cleaned up [03:55] axw: the undertaker will restart if there is an error [03:55] and the other uses are in migration [03:56] and I can work with menn0 to make sure those are retried if necessary [03:59] thumper: thanks [03:59] thumper: LGTM with comment fix [03:59] axw: ta [03:59] * thumper waits for test run to complete [04:01] PASS: allwatcher_internal_test.go:940: allWatcherStateSuite.TestStateWatcherTwoModels 305.009s [04:01] this test seems excessively long [04:01] axw, was that 6 minutes for one test? [04:02] natefinch: I guess you mean thumper [04:02] natefinch: yes [04:02] axw: oops, sorry, yes [04:02] 11.5 minutes for the whole package [04:02] thumper: good lord [04:03] 5 minutes for that one [04:03] er yes, 5, bad math penalty. [04:05] * anastasiamac impressed with thumper's machine - my machine panics as off late while running all tests in state package [04:12] Bug #1605050 opened: Controller doesn't use tools uploaded with juju bootstrap --upload-tools [04:15] anastasiamac: just provide the timeout option [04:15] mine takes > 10 minutes too [04:15] thumper: can you recall - what is the error if you try and deploy to a dying model [04:16] I don't recall [04:16] thumper: \o/ yep, test.timeout is super-useful :D [04:16] thumper: tyvm [04:29] * thumper is looking at this very slow test [04:33] hmm... [04:33] menn0: got a minute? [04:33] thumper: give me 30s [04:33] k [04:36] hmm... [04:36] I wonder if this fix is safe [04:36] 305s -> 6s [04:37] thumper: ok, what's up? [04:37] 1:1 ? [04:38] yep [04:49] thumper: ok back again [05:12] Bug #1605057 opened: allWatcherStateSuite.TestStateWatcherTwoModels takes > 5 mintues

[05:15] w00t [05:16] test win of the day [05:17] menn0: http://reviews.vapour.ws/r/5286/ [05:17] thumper: looking [05:21] Bug #1605057 changed: allWatcherStateSuite.TestStateWatcherTwoModels takes > 5 mintues

[05:22] menn0: if you have a txn.Op with an assertion but no Insert/Remove etc, and it is the only op, what happens if the assertion fails? [05:22] I mean as a []txn.Op [05:22] but it is the only one [05:24] thumper: then an ErrAborted is returned (I guess) [05:24] axw: here's a fix for that deleted model bug http://reviews.vapour.ws/r/5287 [05:24] thumper: and we should be careful with this kind of thing. remember it seems to encourage mgo/txn to create runaway txn-queue fields [05:24] Bug #1605057 opened: allWatcherStateSuite.TestStateWatcherTwoModels takes > 5 mintues

[05:25] menn0: ack, I'll do something else [05:25] thumper: review done. looks good. just a couple of minor suggestions [05:34] wallyworld: reviewed [05:35] ta [05:38] axw: i was using the "Word of God", but yours is better :-) [05:39] wallyworld: lol [05:39] axw: also, william has indicated in the past that he hates a generic notfound code used everywhere [05:39] but i can ask again [05:40] * thumper is done for the day [05:40] laters folks === akhavr1 is now known as akhavr === frankban|afk is now known as frankban [07:34] Bug #1605096 opened: Juju 2.0 Resource Error - sha mismatch error while re-deploying the charm [08:10] menn0: Nice spotting on the upload tools problem! [08:18] fwereade: hey, i have a small PR which uses a new bespoke error code for a model which is no longer there (ie model not found). andrew looked but wanted your +1 on using the new error code. i'm sure we've talked in the past and not just using generic notfound everywhere is preferred. could you take a look? http://reviews.vapour.ws/r/5287/ [08:19] i need to land this for beta13 so if you +1 could you hit $$JFDI$$ for me as i need to head to soccer for a bit [08:33] babbageclunk: just finishing en email to you with a few bits [08:33] wallyworld, LGTM, I left a trivial issue open but I'm happy to land it [08:33] menn0: Cool cool [08:34] babbageclunk: sent! [08:34] * menn0 has to run for now. will check in again later [08:37] menn0: kthxbye [08:37] ha... we're not actually using the uploaded tools? well, that explains some of the oddness. === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr [09:57] * fwereade is trying to arrange for the split water main outside the house to be dealt with, might not make the meeting [10:34] Oh no, I totally missed the meeting! I got the 10-minute reminder but was wrestling with a patch and forgot about it by 11. :( [10:57] babbageclunk: back again for a bit [10:57] menn0: oh hai [10:57] menn0: Replied to your message. [10:58] babbageclunk: just reading that now [10:59] babbageclunk: your modification LGTM. it's a little more correct that way isn't it. [11:01] babbageclunk: does all look well when you run this under your test? [11:01] yup [11:03] fwereade: thanks for +1, back from soccer, will land after eating [11:23] menn0: So, for the logging were you suggesting a sync.Once living at global scope, and then a call to Do from Query.Apply? [11:25] babbageclunk: or newSession or something? you don't want it too early, certainly not at import time, because logging may not be set up properly yet. [11:26] menn0: Ok, makes sense - and the key thing is that the once lives at package scope so that it doesn't log once per session. [11:26] babbageclunk: yep exactly [11:38] babbageclunk: menn0: 10 runs in, no errors yet [11:38] stokachu: Awesome! [11:38] stokachu: ok great. [11:38] stokachu: please give it a bit more testing if you can [11:38] im going to let them run about 4 hours [11:39] That should do it :) [11:39] :D [11:39] ill post my findings before lunch [11:42] menn0: Do we set mgo's logger in juju? I can't see a SetLogger call anywhere. [11:42] babbageclunk: I don't think you want to use mgo's logging infrastructure in this case [11:42] import loggo, create a logger with loggo.GetLogger and use that [11:43] that'll feed straight into juju's logging system [11:43] menn0: Ok, sounds good. === akhavr1 is now known as akhavr [12:06] menn0: Probably doesn't matter, but: logging at info level? Questionable but means we can be sure it we'd see it without the reporter having to change the log level. [12:08] menn0: https://github.com/babbageclunk/mgo/commit/17abfbbc91fbb6a37e682946a8d423b1f7c4633d [12:08] babbageclunk: I thought the default log level was WARNING, not sure though [12:08] menn0: In Juju? [12:08] yep [12:09] huh [12:09] It starts at DEBUG and then at some point during agent startup the model's logging config is applied [12:09] if there hasn't been an explicit one specified a default is used [12:09] * menn0 checks [12:10] babbageclunk: TBH this message is almost certainly going to appear before the model's logging config is applied so may it's a moot point [12:10] Ok, I'll do it as debug and make sure I can see it in a bootstrap. [12:14] babbageclunk: sounds good [12:14] babbageclunk: i'm off. past bed time here [12:55] Can someone who knows about Juju logging help me? I've added the logging I was discussing with menn0 ^^, but I can't see it in logs after bootstrapping. [12:56] babbageclunk, am pretty sure that `juju set-model-config logging-config=INFO` will set the level globally [12:57] babbageclunk, also take note of maybe wanting to log some things in the controller model and some in the hosted model [12:57] babbageclunk, s/log some things/see some logs/ [12:58] fwereade: So I should check machine-0.log on the controller and in (say) default? [12:59] fwereade: I've changed the place where I log to be a warning but it still doesn't seem to show up either on the controller or a machine that I add. [12:59] babbageclunk, huh [12:59] fwereade: Do we log to mongo? [12:59] https://github.com/go-mgo/mgo/commit/071b5646959162617d7356b49be8f419e5f8229c [13:00] babbageclunk, we do; I am brainfarting on exactly where the code lives [13:01] I'm logging in a sync.Once in session.Dial. If the log writer calls Dial, then maybe that first message gets dropped on the floor (since the writer's being set up) and then the message never gets logged again (because Once)? [13:01] babbageclunk, hmm, I am a little loath to suggest it but I would be inclined to use the mgo logging stuff there [13:02] Bug #1605241 opened: juju2beta12 lxd instances not starting

[13:02] babbageclunk, and use mgo.SetLogger to give it something that near-enough matches what it expects [13:02] fwereade: Where would the logging go? Oh, whereever the logger writes to. [13:02] babbageclunk, which can itself be wrapping a loggo.Logger [13:02] la [13:03] * perrito666 wrong window [13:03] fwereade: Wouldn't that mean my patch would need to patch something within juju/juju? [13:04] babbageclunk, as a patch to mgo alone, I think it should use mgo's existing logging facilities [13:04] babbageclunk, if we wanted to make use of it in juju, we can/should separately register a logger for mgo so the output goes where we want it [13:05] fwereade: But there's nowhere in juju/juju that already calls mgo.SetLogger [13:05] babbageclunk, this is true -- what's the high level goal here? to get something in juju's logs that tells us that mgo did the right thing? [13:06] babbageclunk, if so, I think we should be using the existing mgo logging [13:06] babbageclunk, if not, sorry I misunderstood :) [13:06] fwereade: Just so we can tell that the juju running has the patch without torture testing (like stokachu's doing now) [13:07] fwereade: but the existing mgo logging isn't hooked up, so I'd need to make a separate change to do that. [13:07] babbageclunk, and I'm not sure that would be super-helpful either... we probably don't want to risk logging db ops to the db [13:08] fwereade: yeah - I think that's kind of the problem I'm hitting. [13:08] babbageclunk, so, how about exposing `mgo.HasAppliedE11000Patch() bool` and logging that explicitly in controller setup? [13:09] babbageclunk, which can just Once the patch and return true? [13:09] that's weird though, logging shouldn't be what triggers it [13:09] fwereade: Would I have to do that with reflection in the Juju code? Otherwise no-one would be able to build without applying the patch. [13:10] (Which might be a good thing.) [13:10] babbageclunk, ha. dammit again :) [13:10] babbageclunk, although, yeah [13:10] babbageclunk, that may very well be a good thing [13:11] babbageclunk, I am not comfortable developing against arbitrarily-varying dependencies [13:11] fwereade: probably means we'd need better (some) tooling to apply/unapply patches. [13:12] babbageclunk, it would, and we were just discussing in the tech board how we probably didn't want to devote effort to it because we wanted this situation to be rare and not encourage it [13:12] fwereade: crazy idea - in the once, start a goroutine that waits 2 seconds and then logs the patch message. [13:13] * babbageclunk felt bad typing that. [13:13] * fwereade peers disapprovingly over half-moon spectacles [13:13] * babbageclunk is just going to try it for shits and giggles. [13:14] Bug #1605241 changed: juju2beta12 lxd instances not starting

[13:15] * fwereade -- if such a thing lands -- will try to arrange matters such that he gets to hunt you for sport ;p [13:15] babbageclunk, but, yeah, see if it makes a difference [13:16] Would at least confirm that that's the problem. [13:16] babbageclunk, I am generally uncomfortable with our using logging as this sort of data channel, *and* with adding a loggo dependency to mgo... [13:18] babbageclunk, ...but I don't have a better answer offhand, I must admit [13:18] fwereade: This logging is only intended to be in the patch - it'll never go upstream, and will be gone when the patch can go. [13:18] fwereade: but I know what you mean. [13:19] babbageclunk, there's nothing so permanent as a temporary fix [13:19] quite [13:19] babbageclunk, how will we know when we're using a fixed upstream build? ;p [13:19] babbageclunk, unless that also logs... [13:20] Bug #1605241 opened: juju2beta12 lxd instances not starting

[13:21] The problem with the patch is there's no place we can look to determine whether a binary includes it - if the binary is tagged with a hash we can at least look in dependencies.tsv and follow the chain. [13:23] babbageclunk, (can we abuse the flag package to accept `-mgo.ensure-e11000-flag` or did we isolate it well enough that we can't? ...not that that's any better really anyway) [13:25] babbageclunk, wondering about env vars... they're probably the least worst globals I know... [13:27] * fwereade actually has no idea [13:27] sorry [13:28] Hmm. Am I looking in the wrong place? [13:28] Is everything in machine-0.log on the controller machine? [13:30] babbageclunk, I most often just use juju `debug-log --replay` to get it locally so long as the system's generally functioning sanely [13:30] babbageclunk, with appropriate `-m whatever` [13:30] ok - that's what I'm doing (with -m controller) [13:31] bums, I was sure that would work. [13:32] babbageclunk, hey [13:32] babbageclunk, can you just make it write out a file somewhere..? say, in the standard temp dir, whenever it starts? [13:33] Yeah, that seems extremely obvious now. [13:33] I can definitely do that. [13:33] babbageclunk, cool [13:33] fwereade: Thanks! [13:33] babbageclunk, a pleasure :) [13:34] * babbageclunk just wasn't expecting this to be so hard! [13:34] I guess that's all of software in a nutshell. [13:34] babbageclunk, never a truer word was spoken [13:37] babbageclunk, that still does have the what-will-a-fixed-upstream-build-do problem, though [13:37] I was thinking about putting the time in it, but I guess that's really just the mtime of the file. So an empty file it is! [13:39] fwereade: Well, it won't write the file, but we'll be able to see that the PR was merged into the commit. It's just normal change-management stuff, isn't it? [13:39] fwereade: (I'm not sure I understand the problem.) [13:44] babbageclunk, yeah, if it's just an internal check that's fine -- but if we expect anyone in the field to need to check it, surely we should always write it forever? [13:45] babbageclunk, i.e. if it's just for us, to have confidence that it was applied in build X, we can trigger the write on an env var and just make that one of the things we do until we merge the new version [13:45] babbageclunk, if it's not just for us it's 1000x harder [13:46] fwereade: I think it's just for us. [13:47] fwereade: why an env var? [13:47] fwereade: (as opposed to unconditionally) [13:49] fwereade: Ha ha - what if trying to log from inside dial was triggering a panic due to infinite recursion and then loggo was suppressing that? [13:53] babbageclunk, just because it's nicer not to dump the file wherever we run in production [13:53] babbageclunk, (that would be engagingly horrifying) [13:56] fwereade: yeah, makes sense - is it hard to set the env var so that it's set before the controller agent gets bootstrapped? Or would we check the env var each time, and only once.Do the writing when the env var was true [13:56] ? [13:59] babbageclunk, I was imagining that patched-mgo could have an init() that checks the var, writes the file if true, and that's all [14:00] fwereade: ok, but how would we set the env var on the bootstrapped machine in time for that? I guess we could set the var and bounce jujud. [14:01] katco: ping for standup [14:22] fwereade: ha ha, I'm lame - all my theorising was for naught. The real problem was that I was logging in Dial, which we never call, and not in DialWithInfo. [14:23] babbageclunk, haha, bad luck [14:23] So just logging with loggo works fine. [14:23] babbageclunk, ok, please decorate it with suitably apocalyptic warnings about the terrible practices and I'm happy [14:24] ;p [14:24] wilco! (At least it's not the asynchronous logging with a sleep version. I really only suggested that to push the overton window across. :) [14:25] fwereade: I can send an email about what we're doing with interactive commands... gotta run, will be back in an hour and a half, which I know is getting late for you. === natefinch is now known as natefinch-afk [14:29] natefinch-afk, I might stop then but will try to be back later [14:36] dear lazy-web, anybody know off-hand if Python 3's standard library has YAML support (reading/writing) baked in? [14:38]