[02:04]  * babbageclunk goes for a run
[04:02] <thumper> otp
[04:17] <axw> thumper: robot again
[04:18] <thumper> it normally settles down
[04:18] <thumper> not sure why it does this
[04:24] <thumper> axw, jam: I'm going
[04:47] <babbageclunk> axw: ping?
[05:05] <axw> babbageclunk: pong
[05:07] <babbageclunk> axw: hey - just tried an lxc-lxd upgrade with an IS chap - it returned an error about unknown config key lxd.hook.mount
[05:07] <babbageclunk> axw: how do you think I should handle that?
[05:08] <babbageclunk> I haven't been able to find anything on lxd mount hooks on the web.
[05:08] <axw> babbageclunk: lxd.hook.mount? or lxc.hook.mount?
[05:09] <babbageclunk> axw: oops, the latter
[05:09] <axw> babbageclunk: can you check what the hook is? I haven't come across that one in my testing
[05:10] <babbageclunk> From here https://linuxcontainers.org/lxc/manpages/man5/lxc.container.conf.5.html it's a script that runs after mounting is done but before pivot_root, whatever that is.
[05:11] <axw> babbageclunk: yeah, this is on bootstack? I think I found a charm that's setting that in lxc config
[05:12] <babbageclunk> axw: yup - I think they're using it to set static routes in the containers.
[10:14] <axw> rogpeppe1: sorry, my PR is a bit messy. I would appreciate your thoughts on the general approach
[10:14] <axw> it started out as a targeted PR, then morphed along the way
[10:14] <rogpeppe1> axw: i just looked at it in passing tbh.
[10:14] <rogpeppe1> axw: i don't really understand it, i'm afraid, or quite what the eventual motivation is
[10:15] <axw> rogpeppe1: ok. motivations are in the description, which I take I didn't express well :)
[10:16] <axw> rogpeppe1: gotta eat dinner and then go out, will try again tomorrow
[10:18] <rogpeppe1> axw: ok, i think i understand the motivation a bit more now
[10:18] <rogpeppe1> axw: but... if we moved to something like Raft, would we really keep all the Op crap?
[10:19] <axw> rogpeppe1: not the underlying ones, no. but the high level operations, yes - they're the ones that would map to log entries
[10:19] <axw> rogpeppe1: i.e. DestroyUnitOperation et al. would be made serializable, and would be a log entry
[10:19] <axw> that's my vague idea atm anyway
[10:20] <rogpeppe1> axw: ok, that seems reasonable
[10:20] <axw> there'd need to be another sort of entry for ops in a transaction
[10:20] <rogpeppe1> axw: but for mongo, i'm not entirely convinced that arbitrary operations can be composed
[10:21] <axw> rogpeppe1: no, they can't, but we do it already... :)
[10:21] <rogpeppe1> axw: this will only make it worse, right?
[10:22] <rogpeppe1> axw: because people will *think* they can compose a NewService op with a DestroyUnit op, for example
[10:22] <axw> rogpeppe1: hmm, I'm not sure. I guess it would encourage it for future operations. for existing ones, I don't think they're going to be any worse
[10:22] <axw> I mean State.AddApplication adds both application and unit ops; if we compose them outside, yo uget the same result
[10:23] <rogpeppe1> axw: anyway, i'd like to see a more focused version of the PR so that it's clear what changes are as a result of the introduction of ModelTransaction
[10:23] <axw> rogpeppe1: ok, will try and do that tomorrow
[10:23] <rogpeppe1> axw: yup, that's true for AddApplication specifically, and it's tested that way
[10:24] <axw> fair point. bounded badness
[10:24] <rogpeppe1> axw: but i'm concerned that if we provide arbitrary composition, that things will fail easily
[10:24] <rogpeppe1> axw: also, it's very easy to blow the txn doc size limit
[10:24] <rogpeppe1> axw: (we already do in some cases)
[10:27]  * axw out