PMM-15186 Fix for invalid TLS when using change.

[JiriCtvrtka]

https://jira.percona.com/browse/PMM-15186

PMM PR: percona/pmm#5707

[JNKPercona]

Server docker: perconalab/pmm-server-fb:PR-4575-ef096e0
Client docker: perconalab/pmm-client-fb:PR-4575-ef096e0
Client tarball: https://s3.us-east-2.amazonaws.com/pmm-build-cache/PR-BUILDS/pmm-client/pmm-client-PR-4575-ef096e0.tar.gz
Staging instance: https://pmm.cd.percona.com/job/pmm3-aws-staging-start/parambuild/?DOCKER_VERSION=perconalab/pmm-server-fb:PR-4575-ef096e0&CLIENT_VERSION=https://s3.us-east-2.amazonaws.com/pmm-build-cache/PR-BUILDS/pmm-client/pmm-client-PR-4575-ef096e0.tar.gz

[JNKPercona]

API tests have failed: https://pmm.cd.percona.com/job/pmm3-api-tests/7438/

[travagliad]

FB triage — not your change. All 5 red checks on run 35602792321 (@mongodb-exporter, @nomad, @rta, and @user-password on both docker and podman) died in setup, before a single test executed — four at gpg --batch --keyserver keyserver.ubuntu.com --recv-keys … inside the PSMDB container build (qa-integration/pmm_psmdb-pbm_setup/Dockerfile), and the podman one at sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 8919F6BD2B48D754.

keyserver.ubuntu.com is down: replaying the same lookup from a different network still returns 503 upstream connect error or disconnect/reset before headers … connection timeout from its own edge as of 13:31 UTC, while the identical query against keys.openpgp.org returns the key normally. One caveat while reading this run: the other MongoDB/PSMDB checks are green only because their Launchable subset was empty — their Setup PMM Server / Execute e2e tests steps are all skipped, so they ran zero tests and are not evidence either way.

Next step: PMM-QA is removing the single-keyserver dependency from both call sites (fetching the keys from their vendor HTTPS endpoints instead, with the fingerprints still pinned). I'll link the fix PR here. A re-run of the failed jobs should go green once keyserver.ubuntu.com recovers — nothing in this PR needs changing.

---

Generated by Claude Code

[travagliad]

Resolved — your PR is green. keyserver.ubuntu.com came back at 13:48 UTC, so I re-ran the five failed jobs: all five passed (attempt 2, 13:48→14:01) and run 35602792321 now concludes success. These were real executions, not empty-subset skips — Skip notice is skipped and the test step (Execute e2e tests / Run UI tests) concluded success in every one of the five.

On the PMM-QA side the underlying fragility is fixed in percona/pmm-qa#1466: the PSMDB container build and the podman runner now fetch their GPG keys from the vendors that publish them (Percona, CentOS, Fedora/EPEL, ClickHouse) with the fingerprints still pinned, instead of a single keyserver. Verified by running CI's exact failing command on a throwaway VM. That also fixes a pre-existing mislabel the investigation turned up — the Dockerfile was importing the EPEL 8 key into a file named RPM-GPG-KEY-EPEL-9.

Nothing needed on this PR.

---

Generated by Claude Code