Update the base images used by LPL-maintained services to supported/current images.

This task covers one maintenance cycle. The base images should be reviewed periodically (roughly quarterly), but each review should be a separate completable task rather than keeping this task open indefinitely.

Scope

The current LPL service base images are:

For Apertium, the update to the newer Trixie base image has already identified that mirrors.wikimedia.org is no longer available. The existing patch updates the build accordingly.

For the Python services, verify that their Python/system dependencies and container build steps are compatible with the Trixie-based image.

If an individual service requires substantial application changes rather than a straightforward base-image update, split that work into a separate task.

Acceptance criteria

• All LPL service base images listed above have been reviewed.
• Apertium uses a current supported Trixie base image and its container builds successfully.
• Machine Translation uses python3-build-trixie and builds/tests successfully.
• Recommendation API uses python3-build-trixie and builds/tests successfully.
• CXServer has been reviewed and either:
  • requires no change, or
  • any required update is included/documented.
• Updated service images are tested in staging before production deployment.
• Updated images are deployed to production and the affected services operate normally afterwards.
• Any service intentionally left unchanged has the reason recorded in this task.

Dependencies and prerequisites

No known implementation blockers.

Normal deployment access and review are required for the affected services.

Recommendation API follows its existing ml-services deployment process rather than the deployment process used by the other LPL services.

No documentation, configuration migration, data migration, or coordinated client-side update is currently expected.

QA plan

Risks and affected areas

The main risks are:

• Debian package availability or package names changing between Bookworm and Trixie.
• Python dependencies being incompatible with the Python/runtime environment provided by the new base image.
• Container build/install scripts relying on repositories or infrastructure that are no longer available.
• A service building successfully but failing to start or behave correctly after deployment.

The change should not alter application functionality; expected behaviour before and after the base-image update is the same.

Automated testing

For each changed service:

• The container image must build successfully in CI.
• Existing unit/integration tests must pass using the new base image.
• Dependency installation must complete without relying on unsupported/obsolete repositories.

No new application-level automated tests are required solely for changing the base image.

Staging and manual verification

Deploy each changed image to its normal staging environment before production.

For each service:

• Verify the deployment completes and instances/pods become healthy.
• Exercise a representative API request or normal service operation.
• Check service logs for startup errors, dependency/runtime errors, or other new warnings attributable to the base-image change.

Use the existing service-specific staging procedures, including:

• Apertium: test a translation request through the staging CXServer/Apertium integration.
• Machine Translation: test a translation through the machinetranslation staging service.
• Recommendation API: test a recommendation request against the Recommendation API staging deployment.

There is no need to duplicate these checks in a separate local manual-testing phase; staging is the appropriate integration environment for this infrastructure change.

Production deployment and verification

After successful staging verification, deploy the updated image for each service using its normal production deployment procedure.

After each rollout:

• Verify the new image version is running and instances/pods are healthy.
• Perform a representative production smoke test.
• Check recent service logs/monitoring for new errors.

If a deployment fails or introduces a regression, roll back to the previously deployed image version and investigate before retrying.

Recurrence

After completing this task, create the next base-image review task for approximately three months later. The next task should start by inventorying the base images used by LPL-maintained services and comparing them against currently supported Wikimedia base images.