Change Details

The `httpd` production images, along with the dependent `httpd-fcgi` and `mediawiki-httpd` images, are currently based on buster (apache2 2.4.59). Since upgrading to either bullseye or bookworm gives us apache2 2.4.62, there's no strong argument to step to bullseye first, so let's aim for bookworm. For PHP services, we can use this as a comparatively low-risk test for parts of the procedure we'll use to migrate the app images to 8.1 (e.g., for MediaWiki, it could be used to validate scap's ability to build multiple image "flavors" from different base images, once available). In any case, to do this in a controlled way, we'll need buster- and bookworm-based production images to coexist for a time. I'd propose we do this by introducing a "next" track for the three production images, which would later merge back into the existing ones (which would really just be changing the Dockerfile template in `httpd` and bumping the changelogs). The other notable (static content) use case we'll have to coordinate is updating the various miscweb deployments (https://gitlab.wikimedia.org/repos/sre/miscweb).

The `httpd` production images, along with the dependent `httpd-fcgi` and `mediawiki-httpd` images, are currently based on buster (apache2 2.4.59). Since upgrading to either bullseye or bookworm gives us apache2 2.4.62, there's no strong argument to step to bullseye first, so let's aim for bookworm. For PHP services, we can use this as a comparatively low-risk test for parts of the procedure we'll use to migrate the app images to 8.1 (e.g., for MediaWiki, it could be used to validate scap's ability to build multiple image "flavors" from different base images, once available). In any case, to do this in a controlled way, we'll need buster- and bookworm-based production images to coexist for a time. I'd propose we do this by introducing a transitional "bookworm" track for the three production images, which would later merge back into the existing ones (which would really just be changing the Dockerfile template in `httpd` and bumping the changelogs). The other notable (static content) use case we'll have to coordinate is updating the various miscweb deployments (https://gitlab.wikimedia.org/repos/sre/miscweb).

The `httpd` production images, along with the dependent `httpd-fcgi` and `mediawiki-httpd` images, are currently based on buster (apache2 2.4.59). Since upgrading to either bullseye or bookworm gives us apache2 2.4.62, there's no strong argument to step to bullseye first, so let's aim for bookworm. For PHP services, we can use this as a comparatively low-risk test for parts of the procedure we'll use to migrate the app images to 8.1 (e.g., for MediaWiki, it could be used to validate scap's ability to build multiple image "flavors" from different base images, once available). In any case, to do this in a controlled way, we'll need buster- and bookworm-based production images to coexist for a time. I'd propose we do this by introducing a "next"transitional "bookworm" track for the three production images, which would later merge back into the existing ones (which would really just be changing the Dockerfile template in `httpd` and bumping the changelogs). The other notable (static content) use case we'll have to coordinate is updating the various miscweb deployments (https://gitlab.wikimedia.org/repos/sre/miscweb).