[08:52:26] <wikibugs>	 10serviceops, 10MW-on-K8s, 10SRE, 10Traffic, and 3 others: Migrate internal traffic to k8s - https://phabricator.wikimedia.org/T333120 (10Clement_Goubert)
[14:05:33] <wikibugs>	 10serviceops, 10SRE-OnFire, 10Traffic, 10conftool, 10Sustainability (Incident Followup): Pybal maintenances break safe-service-restart.py (and thus prevent scap deploys of mediawiki) - https://phabricator.wikimedia.org/T334703 (10MatthewVernon)
[15:19:06] <wikibugs>	 10serviceops, 10DC-Ops, 10SRE, 10ops-codfw: hw troubleshooting:  CPU error for mw2448.codfw.wmnet - https://phabricator.wikimedia.org/T334429 (10Jhancock.wm) 05Open→03Resolved no new log entries. closing.
[15:19:56] <wikibugs>	 10serviceops, 10DC-Ops, 10SRE, 10ops-codfw: hw troubleshooting:  CPU error for mw2448.codfw.wmnet - https://phabricator.wikimedia.org/T334429 (10Clement_Goubert) Acknowledged, thank you for checking :)
[15:21:12] <ottomata>	 o/, i'd like to use bullsye to build production-images flink image.  Currently i'm basing the image off of the openjdk-11-jre image, which itself is built on buster.
[15:21:51] <ottomata>	 should I:
[15:21:51] <ottomata>	 A. upgrade openjdk-11-jre to base on bullsye
[15:21:51] <ottomata>	 or
[15:21:51] <ottomata>	 B. base flink on bullsye and install openjdk-11-jre .deb
[15:21:52] <ottomata>	 ?
[15:22:00] <ottomata>	 jayme: ^ ?
[15:24:42] <ottomata>	 hm, one of the reasons i'm doing this is to upgrade to python 3.9.  maybe I should jus use the python/bullsye image and install openjdk-11-jre into hat
[15:27:59] <jayme>	 I'd say add the bullseye java images and bould off of those
[15:28:08] <jayme>	 not sure about python in the mix, though
[15:28:55] <ottomata>	 the image needs both java and python (pyflink)...i'm actually using pip to install flink, so maybe python-bullsye is the better way to go?
[15:29:33] <ottomata>	 it doesn't really matter hough
[15:29:49] <ottomata>	 maybe having bullysye openjdk 11 will be useful to have anyway, i'll start that way
[15:30:38] <jayme>	 yah, I would agree it probably does not matter from where you start if you end up adding jre and python anyways
[15:31:13] <ottomata>	 jayme:  hm, curious, the python/<os> images have the os in the package name (in control) , e.g. 
[15:31:13] <ottomata>	 Package: python3-bullseye
[15:31:16] <ottomata>	 but the java ones do not
[15:31:33] <ottomata>	 e.g. java/buster/openjdk-11-jre/control has
[15:31:34] <ottomata>	 Package: openjdk-11-jre
[15:31:49] <jayme>	 jre images do currently contain a hack for making java packages installable without man installed, though. So it might make sense to use that base
[15:31:56] <ottomata>	 oh that's true
[15:31:58] <ottomata>	 okay
[15:32:14] <ottomata>	 what is the reason/benifit for having different os directories, but using the same Package name in them?
[15:32:14] <jayme>	 but maybe that's fixed with bullseye :)
[15:34:25] <jayme>	 I fear we lack a standard for that (os version in image name)
[15:35:01] <jayme>	 the different directories is just a different approach I suppose - the images there differ by version exstension (-sX)
[15:42:03] <ottomata>	 hm, the versions extensions are the same?
[15:42:30] <ottomata>	 openjdk-11-jre (0.1-s3) in buster
[15:42:30] <ottomata>	 alos
[15:42:39] <ottomata>	 openjdk-11-jdk (0.1-s3) in bullsye
[15:42:45] <ottomata>	 oops i mean jrew
[15:42:51] <ottomata>	 openjdk-11-jre (0.1-s3)
[15:43:20] <ottomata>	 https://docker-registry.wikimedia.org/openjdk-11-jre/tags/
[15:43:29] <jayme>	 I don't see a bullseye image
[15:43:33] <ottomata>	 sorry
[15:43:33] <ottomata>	 hahah
[15:44:00] <ottomata>	 i forgot I copied the buster dir to bullsye already, ignore ^^^ :p
[15:44:09] <ottomata>	 i see
[15:44:16] <ottomata>	 so stretch had jre 8
[15:44:20] <ottomata>	 and buster has jre 11
[15:44:28] <ottomata>	 but since bullsye also jre 11...
[15:44:29] <ottomata>	 hm
[15:44:56] <jayme>	 fwiw I think it's a bad approach how it's done there
[15:45:31] <ottomata>	 yeah, would you prefer: os name in Package image name.  Or: get rid of OS dirs and just use jdk version in package name, and OS is irrelevant
[15:45:36] <ottomata>	 ?
[15:46:26] <ottomata>	 get rid of OS dirs is: e.g.
[15:46:26] <ottomata>	 java/openjdk-11-jre etc.
[15:46:26] <ottomata>	 and, java/openjdk-11-jre/changelog just has a new release with 'upgrade to bullsye' ?
[15:48:49] <jayme>	 I would assume that the initial idea was to not care about os versions (cc joe) which makes automatic upgrades easier and makes it easier to break things
[15:50:00] <jayme>	 php, node and golang images don't carry the os name as well (aside from dev and releng stuff)
[16:00:09] <joe>	 jayme: more or less, yes
[16:00:19] <joe>	 you should care about the version of the language, not the OS
[16:00:27] <joe>	 sorry I'm in neverending meetings today
[16:03:01] * jayme in meeting now as well
[16:24:07] <wikibugs>	 10serviceops, 10SRE, 10CommRel-Specialists-Support (Apr-Jun-2023), 10Datacenter-Switchover: CommRel support for April 2023 Datacenter Switchback - https://phabricator.wikimedia.org/T334671 (10Kappakayala) Hi @Trizek-WMF, We understand that we should have notified to your team earlier. This is part of the s...
[16:58:25] <ottomata>	 (meetings too, but thanks okay, i'll submit a patch to refactor java/ dir then)
[17:04:15] <wikibugs>	 10serviceops, 10Data-Persistence, 10SRE, 10Datacenter-Switchover, and 2 others: March 2023 Datacenter Switchover - https://phabricator.wikimedia.org/T327920 (10cmooney)