[00:54:12] * bd808 off [10:38:19] please do not upload anything to docker-registry.tools.wmflabs.org until futher notice, I'm swapping the active host of that [10:42:10] done [10:49:37] uhh apparently the cloudvps puppetmaster has a certificate called `CN=puppetmaster.cloudinfra.wmflabs.org, puppet, cloudinfra-cloudvps-puppetserver-1.cloudinfra.eqiad1.wikimedia.cloud`.. (yes, that one certificate with one name, not three) [10:49:58] and because the puppet CLI allows you to pass a comma-separated list of certificates to work on, it can't be cleaned up [11:10:45] is that the result of a script/copy-paste from the wiki? [13:30:51] It's probably from me creating a cert with the alt names and misquoting somehow :/ [13:31:12] But I don't think puppet has state about certs outside of the files themselves so probably just removing the file is adequate [15:25:12] taavi: I should be running the add_node_to_hiera cookbook before the add_node_to_cluster cookbook, right? [15:26:20] andrewbogott: you should be running the top-level cookbook that does everything [15:27:27] oh, so that's wmcs.toolforge.add_k8s_etcd_node. I will stop doing this the hard way :) [15:27:40] so wmcs.toolforge.add_k8s_etcd_node [15:27:46] yes :-) [15:55:39] taavi: think these cookbooks have been used/updated since we added our localstorage cloudvirts? It seems to be having trouble scheduling new nodes (even though if I create from the openstack cli it works fine) [15:56:54] good question. look at the spicerack logs to see what it's trying to do I guess? [15:57:28] yeah, I'm happy to debug, was just wondering what to expect [16:01:38] taavi: thanks for the warning banner about Bookworm on https://wikitech.wikimedia.org/wiki/Help:MediaWiki-Vagrant_in_Cloud_VPS [16:02:33] ok, it's because it's trying to schedule on a host that doesn't already include a node, of which there aren't any [16:04:39] c-team: There are 13 Cloud VPS projects using MediaWiki-Vagrant today. They are blocked from Bookworm upgrades by unmaintained upstream software (vagrant-lxc plugin) and longer term face Vagrant's piviot to a non-libre license. Thoughts about new ways we can help folks provision non-trivial MediaWiki deployments are welcome. [16:05:08] This might be something that catalyst/next-gen patchdemo helps with, but that is unclear at the moment. [16:07:17] limavm work ok for us for lima-kilo, though it's a way simpler use-case than mediawiki vagrant [16:07:25] so not sure if it will have all the features required [16:07:47] (might also be a lot of work to port) [16:09:19] Worth thinking about at least. Part of the historical magic of MediaWiki-Vagrant on Cloud VPS was piggybacking on the actively maintained dev environment. That hasn't been a big selling point for quite a while unfortunately. [16:11:03] My first though is that we should kick the can to Bullseye and then hope that Catalyst has an actual better solution by the time Bullseye is EOL [16:11:20] And if the catalyst folks want use cases, we've got 'em! [16:12:46] I *think* long term wikis are a fork from the MVP for catalyst/patchdemo, but fallout tech at least is possible. And you're probably thinking in the most near term sustainable way there andrewbogott [16:13:36] That's a good point, we might need a long-term wiki hosting alternative :/ [16:13:46] So far it looks like local dev is not going to get a major push next fiscal, but catalyst should. [16:14:26] There are also potential benefits coming from improvements in the mw-on-k8s story next fiscal [16:15:36] If we get the imagined single version, trunk containers that group-1 would want they might be reusable for things like wikispore [16:16:36] I also keep wondering what a buildpack (I think that's the right term this time dcaro) for MediaWiki + extensions might look like [16:17:20] A buildpack for mw hosting seems like the fanciest option [16:17:57] I think a major feature of mw-vagrant that other things haven't quite hit yet is managing LocalSettings for a large collection of extensions. [16:18:00] I that that would be the name yes, though the buildpacks support only one container, so if you want to be able to manage mariadb + whatever, you'd have to start them somehow inside the same container or have different containers for the services (probably best?) [16:18:21] * dcaro is not very familiar with mediawiki vagrant) [16:18:57] * taavi hears mariadb and container and toolforge and gets scared due to NFS [16:18:59] mw-vagrant is functionally a vm + a very large pile of puppet that provisions wikis and other services in the vm [16:20:25] the buildpack/container stuff I'm thinking about right now would just be the MediaWiki PHP code and config bits behind some webserver. database and other support services would be external dependencies [16:21:48] a grouping of [mw]-[mariadb]-[redis replacement] containers would cover a lot of deployment needs [16:23:18] those needs probably have a high overlap with local dev needs for most MW developers too, except with the add-on of wanting to live edit code and config and ship patches to gerrit [16:34:30] that makes sense yes, that would be doable I think [16:49:09] I should probably try to get some of these things out of my head and into phab or wiki pages where others can pick them apart and fix the goofy bits [17:08:02] sharing always helps :) [17:08:05] * dcaro off [17:08:08] cya on tuesday [18:05:43] taavi: quick review of https://gerrit.wikimedia.org/r/c/operations/puppet/+/1015363 if you're about? [18:21:07] * bd808 lunch [21:16:33] * andrewbogott -> the treadmill