[08:40:13] Hello folks! I noticed https://gerrit.wikimedia.org/r/c/operations/docker-images/production-images/+/976663 [08:40:52] I didn't know about it, I assumed the Spark images would have been rebuilt to pick up security upgrades.. [08:41:19] maybe we could move big images to something like biweekly? [08:43:21] heh, I had missed the change too. I knew that we skipping something, now I connected the dots [08:43:48] how long do they take to build? do we have a number? [08:43:53] I am asking since ML is following the same, asked to skip pytorch images [08:44:19] the Spark ones are really long, pytorch I'd say 10 mins each max [08:44:27] Spark could last for more probably [08:44:45] we could think about having a separate rebuild for big images, maybe? [08:44:54] biweekly, doesn't impact the rest [08:45:25] but it is already difficult to track down security upgrades for the non-production-images Docker images :D [08:45:31] well, something for sure. Now as to how and when, depends on the apps requirements I suppose [08:49:29] for jvm-based stuff, like spark, I'd be ok to rebuild less often, since the updates a quarterly based [08:49:38] in case of something nasty we can always force a rebuild [08:52:21] in the last round of upgrades I missed the spark images, in fact see https://debmonitor.wikimedia.org/packages/openjdk-11-jre-headless (upgradable packages) [08:53:38] I'll force a rebuild for this case [08:53:53] in other news, all dragonfly supernode hosts are on bookworm [08:54:16] <3 thanks luca! [09:03:48] filed https://gerrit.wikimedia.org/r/c/operations/docker-images/production-images/+/1072150 for the spark images [10:15:44] --- [10:16:21] follow up for the security upgrades - I realized that we are missing all the DE's images running on DSE (or most of them) in Debmonitor since they are in gitlab [10:16:25] so I filed https://gerrit.wikimedia.org/r/c/operations/puppet/+/1072163 [10:16:42] I think it should be fine to couple it with our current job, but lemme know if you prefer another one [10:17:06] in theory the worst part is getting the catalog from the registry, once we have that it should be relatively straightforward [13:10:31] FWIW, I don't think the spark images are in active use anywhere (yet) [13:10:36] cc btullis [13:10:56] ottomata: o/ the spark operator is deployed on DSE [13:26:50] Thanks both. Yeah, we can update the spark-operator deployment with the new version. Andrew is right that `spark` itself isn't executed unless someone creates a `SparkApplication`object on dse-k8s. [13:28:35] Then the operator launches the drive and executor pods running spark. As it happens, we created some yesterday (calculating pi) for testing T369492 (Migrate dse cluster off of Pod Security Policies) [13:28:36] T369492: Migrate dse cluster off of Pod Security Policies - https://phabricator.wikimedia.org/T369492 [13:32:21] We would also like to move the spark images to GItLab. The only reason we haven't is the handy feature from `docker-pkg` that doesn't build an image if it has already been published. There is no GitLab-CI equivalent, as far as I can tell. [13:47:45] I added today support in docker-reporter for the gitlab images on our docker registry, after the next run we should see the images in Debmonitor