[07:14:04] <_joe_> dduvall, inflatador adding metadata to images is something we wanted to do for some time. Specifically the parent images are particularly important for some of our processes [07:14:43] <_joe_> we should agree on what metadata we want besides provenance, and inject it from both kokkuri and docker-pkg [07:14:48] <_joe_> so our images are consistent [09:11:05] hey folks, heads up that there are staged changes to /var/lib/git/private on puppetmaster1001, and I think it would break any puppet private change (the post-commit hook) [09:11:16] working on it, if you have to puppet-private commit ping me first please [09:32:02] this may have been ongoing for a bit, afaics gitpuppet can git-pull with staged content on /var/lib/git/operations/private [09:34:25] elukey: changes to /srv/private should be done on which machine right now? [09:35:24] puppetmaster1001, we didn't change it yet.. in the future puppetserver1001 [09:35:41] I mean I'd love to announce the change, but I found this nice "feature" :D [09:39:57] ack [10:00:38] fixed the repo manually, still not sure what's happening [10:00:52] but it must be the dump cloud ip ranges script [10:25:55] could it somehow crash before the end and leaving the directory in a half-committed state? [10:27:17] in theory the script works on another dir, /srv/private, meanwhile the staged content is on /var/lib/git/operations/private [10:27:22] this is what puzzles me [14:23:51] urbanecm: can you please respond on https://phabricator.wikimedia.org/T369914 ? [14:25:11] andrewbogott: sure. just started the evening hours of meetings, will try to reply to that after meetings or tomorrow. [14:25:26] thanks, likely a one word reply is all that's needed [15:28:09] andrewbogott: responded [15:28:16] thank you! [15:28:37] np [15:53:39] We use a variety of diagramming software for our documentation - are there any strong feelings one way or another? It'd be pretty cool if wikitech supported diagramming via an extension or something (https://phabricator.wikimedia.org/T183689) [15:53:57] In the meantime... I'm unsure of what I should use for more involved diagramming [15:54:14] brett: the latest hotness is https://mermaid.js.org/ [15:54:24] I thought that was the old latest hotness :P [15:54:34] There *is* a mermaid mediawiki extension... [15:55:20] I like how I subscribed to that ticket two years ago and still don't know what to use O:) [15:56:20] What matters to me is being able to edit later down the line when things inevitably change [15:56:34] what's wrong with dot? :-P [15:56:47] I use draw.io, paste the png to wikitech and a link to the xml [15:56:54] example https://wikitech.wikimedia.org/wiki/Server_Lifecycle#Server_transitions [15:57:01] the source is saved in the repo [15:57:13] dot gets instantly gets awful when you have more than a few nodes :P [15:58:19] draw.io was attractive - pasting a link to the shared gdrive file in the file page description [15:58:49] I prefer it as code but that seems easiest long-term [15:59:45] <_joe_> I disagree that complex dot graphs are unreadable messes, i have a prime example [15:59:48] <_joe_> https://people.wikimedia.org/~oblivian/arrow-hell.png [15:59:59] hahahahaha [16:00:06] It's beautiful [16:08:43] * Emperor still uses PGF/tikz for diagrams [16:26:59] dhinus: FYI new spicerack release is out (v8.10.0) nothing that affects WMCS though ;) [16:36:34] Heads up, we finished deploying some changes on restbase and changeprop. Things look OK so far. [16:56:03] volans: thanks! [17:59:49] _joe_: re: metadata, the blubber buildkit gateway is reusing upstream's `dockerui` package which essentially makes it compatible with all `docker buildx` options for both sbom and provenance generation. i.e. the metadata formats created by `docker buildx build --sbom --provenance` will be the same whether using blubber or a dockerfile, so if we refactor docker-pkg to use `docker buildx`, we would get the same type of metadata [18:00:37] <_joe_> dduvall: I wanted to make a buildkit driver for it, eventually [18:00:54] <_joe_> so that we can move production-images to gitlab and build and publish images directly [18:01:02] <_joe_> I just never have time [18:01:05] oooh, that would be nice [18:01:44] afaik, `docker buildx` doesn't need a docker daemon running, so it may be quite easy to get running in gitlab [19:46:21] i'm looking to run the sre.dns.netbox cookbook to decommission a few hosts. they have different tasks for the hosts. it looks like it will only take a single task-id so just wondering if there is a standard way to approach this. [19:47:31] my gut reaction would be to leave out the task-id and make sure all the hosts are noted in the message. [19:54:08] the "standard" way I guess is that we (some teams?) have a unified decommission task that has all the hosts; example T352253 [19:54:08] T352253: Decommission task for old cp hosts (cp1075-1090) - https://phabricator.wikimedia.org/T352253 [19:54:30] but the cookbook makes a note of the hosts being decommed in the SAL output so your strategy should be OK [19:55:18] ah. cool. i'll do that for our next wave. thanks!