CLOUDP-337357 - Migrate all agents script

[lucian-tosa]

Summary

This pull request introduces a new manual pipeline for migrating and publishing all agent images to a new registry. The main changes add support for running this migration as a manual task in Evergreen, including the necessary pipeline configuration, scripts, and build variant.

Evergreen pipeline and build variant additions:

• Added a new pipeline_migrate_agents function to .evergreen-functions.yml, which runs the pipeline_migrate_agent.sh script for agent migration.
• Added a new migrate_all_agents task to .evergreen.yml, enabling manual execution to build and migrate all agent images.
• Created a new publish_agent_images_manual build variant in .evergreen.yml, allowing patch requesters to trigger the migration task.

Script additions for manual migration:

• Added scripts/release/pipeline_migrate_agent.sh to execute the migration logic using the main pipeline Python script, targeting the new registry.

To trigger this task, the following command will be run

evergreen patch -p mongodb-kubernetes -v migrate_all_agents -t migrate_all_agents -y -f -u --browse -d "" --param evergreen_retry=false

Proof of Work

This patch migrates all the agents to my private ECR
There are 17 agents in release.json. For each of them there will 4 be images (4 architectures), 1 aggregated manifest, and one signature, therefore 102 entries.

This patch ran the static tests using my private ECR registry.

Checklist

• Have you linked a jira ticket and/or is the ticket in the title?
• Have you checked whether your jira ticket required DOCSP changes?
• Have you added changelog file?
  • use skip-changelog label if not needed
  • refer to Changelog files and Release Notes section in CONTRIBUTING.md for more details

[github-actions]

⚠️ (this preview might not be accurate if the PR is not rebased on current master branch)

MCK 1.3.0 Release Notes

New Features

Multi-Architecture Support

We've added comprehensive multi-architecture support for the kubernetes operator. This enhancement enables deployment on IBM Power (ppc64le) and IBM Z (s390x) architectures alongside
existing x86_64 support. Core images (operator, agent, init containers, database, readiness probe) now support multiple architectures. We do not add support IBM and ARM support for Ops-Manager and the init-ops-manager image.

Bug Fixes

• This change fixes the current complex and difficult-to-maintain architecture for stateful set containers, which relies on an "agent matrix" to map operator and agent versions which led to a sheer amount of images.
• We solve this by shifting to a 3-container setup. This new design eliminates the need for the operator-version/agent-version matrix by adding one additional container containing all required binaries. This architecture maps to what we already do with the mongodb-database container.
• Fixed an issue where the readiness probe reported the node as ready even when its authentication mechanism was not in sync with the other nodes, potentially causing premature restarts.

Other Changes

• Optional permissions for PersistentVolumeClaim moved to a separate role. When managing the operator with Helm it is possible to disable permissions for PersistentVolumeClaim resources by setting operator.enablePVCResize value to false (true by default). When enabled, previously these permissions were part of the primary operator role. With this change, permissions have a separate role.
• subresourceEnabled Helm value was removed. This setting used to be true by default and made it possible to exclude subresource permissions from the operator role by specifying false as the value. We are removing this configuration option, making the operator roles always have subresource permissions. This setting was introduced as a temporary solution for this OpenShift issue. The issue has since been resolved and the setting is no longer needed.
• We have deliberately not published the container images for OpsManager versions 7.0.16, 8.0.8, 8.0.9 and 8.0.10 due to a bug in the OpsManager which prevents MCK customers to upgrade their OpsManager deployments to those versions.

[Julien-Ben]

LGTM ! Good to see the agents available on all these platforms 🎉

[nammn]

the variant name doesn't match the task its running

[lucian-tosa]

changed it now