[03:24:52] ryankemper: should I merge "fix DCAT-AP reload and load it to the categories endpoint" ? [03:27:32] I'm doing it! [03:42:20] andrewbogott: thanks! [11:12:32] cdanis: WTB `dbctl config reset` [11:12:44] such that any uncommitted changes get dropped. [11:13:17] that'd be nice [11:13:37] maybe it can be done after XX minutes by default [11:24:32] kormat: that has the same complexity of the revert of all the normalized objects [11:24:36] IIRC [11:26:05] one option we discussed in the past is that we could (probably should?) take out the normalized part from etcd into a local git (replicated via hooks) and leave in etcd only the denormalized MW view [11:43:46] <_joe_> volans: there are ways around that complexity but yes, the only thing that needs to be in etcd is the mw view [11:50:03] kormat: I saw your ping on my phone while making coffee and was going to say "it's quite hard without a redesign" but I see volans and _joe_ beat me to it [11:56:58] cdanis: if it helps, don't let me get in the way of a redesign ;) [11:57:26] i'm confused, however. how can it show a diff, but not be able to reset? [11:57:49] there's a set of instance and section objects, which are themselves tiny json blobs [11:58:06] those also live in etcd, and are edited (without preserving history) when you do something like `instance FOO depool` [11:58:25] but that's not what mediawiki reads; mediawiki reads the other keys that are generated by the `config` subcommand [11:58:50] when you do `dbctl config diff` it is basically equivalent to doing `diff -u <(dbctl config get) <(dbctl config generate)~ [11:59:15] but, it doesn't know the prior state of those underlying instance/section objects [11:59:30] `dbctl config reset` => `dbctl config get > a; dbctl config load < a`? [11:59:49] you cannot 'load' from a generated config without losing information [12:00:01] oh, lovely [12:00:12] there's a well-defined transformation from "a set of instance and section objects" to "a config object", but not the other way around [12:01:08] we could also have dbctl dump everything out in a format it could load back in, but at some point along the way there, you're just re-implementing a version control system [12:02:03] does all of the earlier discussion make more sense now? [12:02:33] none of it, but i'm going to try rereading it again [12:03:06] https://gerrit.wikimedia.org/r/plugins/gitiles/operations/software/conftool/+/refs/heads/master/conftool/extensions/dbconfig/README.md might help as well [12:10:47] ok, read that, still unclear on some things [12:10:58] what does `dbctl config get` _do_? [12:11:47] my understanding was this: dbctl instance|section etc change the section/instance objects in etcd. dbctl config diff compares that against the mwconfig objects [12:12:01] and hence dbctl config get would be decoding the mwconfig objects [12:12:56] there's a 'rendered' version of the config, mangled into the form Mediawiki expects, also in etcd [12:13:18] that is mwconfig, right? [12:13:21] yes [12:13:29] and config get literally just dumps that current value out of etcd [12:14:05] ahh. so it's not the same format, ok [12:14:07] now i get it [12:14:15] get and generate both work in _that_ format [12:14:22] yep [12:14:25] and so does diff, really [12:17:39] and config load uses the normalised format? [12:17:49] yeah, it has to [12:18:00] yeah, the mwconfig format [12:41:52] kormat: the quick "hack" to cover the revert use case would be to duplicate all the normalized instance/section objects in etcd so that one set is the "committed" one and one set is the working copy one [12:42:21] at that point it will be easy to do a revert, but it feels pretty hacky and the wrong usage of etcd [12:43:01] and it will still not cover the case in which you revert a previous commit (as saved on file) unless we dump those objects too to file [12:43:31] all quite messy and not ideal. Hence the idea that if we want to do this refactor probably better to go towards a real git repo [13:09:05] <_joe_> no, the quick hack is to store somehow the etcd index at which you last committed your changes :) [13:10:03] <_joe_> that allows for the use-case kormat wants (reset what you just did) as long as the etcd index doesn't get compacted [13:15:16] eheheh [14:49:41] moritzm: hey. re: T252027, where should this script live? [14:49:42] T252027: debian-installer: partman doesn't allow lvm LVs to be reused when reimaging - https://phabricator.wikimedia.org/T252027 [14:53:20] kormat: for partman/early_command or the upstream approach? [14:53:30] the former [14:53:43] i've rewritten it to be ~general [14:53:49] (it can now take a recipe of partitions to reuse) [14:54:13] i'm up for submitting it upstream, but i'd like to get it accepted and working here first :) [14:58:10] ah, gotcha, so you mean where it should live in our puppet tree (to get eventually wget-ed from the installing host), right? [14:58:23] "on the installing host" [14:58:33] sorry, yes [14:59:17] cdanis: warning: i'm going to add you to the reviewers list ;) [14:59:39] kormat: homer-bushes.gif [15:03:18] kormat: you can simply add it to modules/install_server/files/autoinstall, anything in there gets install in the preseed environment (currently apt1001/apt2001) in the install_server::preseed_server class and it available via HTTP [15:03:38] ok, great