From ddb1da3572a1a75f9e7546225bd614a1814b753f Mon Sep 17 00:00:00 2001 From: shankar0123 Date: Thu, 30 Apr 2026 23:36:54 +0000 Subject: [PATCH] =?UTF-8?q?fix(deploy/test):=20libest=20IP=20collision=20w?= =?UTF-8?q?ith=20tls-init=20(10.30.50.9=20=E2=86=92=2010.30.50.10)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Two services on the certctl-test bridge network were pinned to the same static IP: certctl-tls-init (line 91) and libest-client (line 472). The pre-Phase-5 per-vendor matrix structurally hid this: - tls-init is profile-less ⇒ always runs - libest-client is profiles=[est-e2e] ⇒ only runs when est-e2e job brings it up - est-e2e and deploy-e2e historically lived in DIFFERENT CI jobs ⇒ separate docker networks ⇒ no collision The collision would surface the moment any single CI job invokes both `--profile deploy-e2e` and `--profile est-e2e`, or the moment a local operator runs `docker compose --profile=*` for full-stack debugging. Pre-emptive fix. Move libest to 10.30.50.10 (next free address; allocated range was 10.30.50.2-9 + 20-30, the entire 10-19 sub-range was unused). NOT the cause of the deploy-vendor-e2e "certctl-test-server is unhealthy" failure in CI run 25194251740 — libest isn't in profile=deploy-e2e and never started in that run. Real cause for that failure is being investigated in a separate commit (CI diagnostic dumping). --- deploy/docker-compose.test.yml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/deploy/docker-compose.test.yml b/deploy/docker-compose.test.yml index 8225f28..382cc86 100644 --- a/deploy/docker-compose.test.yml +++ b/deploy/docker-compose.test.yml @@ -469,7 +469,13 @@ services: - ./test/certs:/config/certs:ro networks: certctl-test: - ipv4_address: 10.30.50.9 + # Was 10.30.50.9 — collided with certctl-tls-init (line 91). Pre-Phase-5 + # per-vendor matrix structurally hid this: tls-init is profile-less so + # it always ran, but libest is profiles=[est-e2e] so it only ran when + # the (separate) est-e2e job brought it up. Different jobs ⇒ different + # docker networks ⇒ no collision. Surfaced when a future job runs both + # profiles together; pre-emptive fix here. + ipv4_address: 10.30.50.10 restart: unless-stopped profiles: [est-e2e]