Run Argo Workflows E2E with the Kubernetes Agent backend - #24827
Conversation
Convert the argo_workflows E2E environment to run the Agent inside the Kind cluster instead of port-forwarding from the host. Since workflow-controller has no backing Service, the pod IP is fetched directly via kubectl and used to build the openmetrics_endpoint. Environment: Datadog workspace Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
🎉 All green!🧪 All tests passed 🔗 Commit SHA: a686e38 | Docs | Datadog PR Page | Give us feedback! |
evalya-impact-summaryevalya impact analysis |
|
@codex review |
|
Codex Review: Didn't find any major issues. Breezy! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
CI failed because dd_environment re-runs get_workflow_controller_pod_ip() on every invocation, including the one ddev env stop uses to tear down the fixture after the Kind cluster is already deleted. Resolve the pod IP once inside setup_argo_wf (which only runs on cluster creation) and cache it with save_state/get_state, matching the pattern used by velero's node-agent lookup. Environment: Datadog workspace Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
@codex review |
|
Codex Review: Didn't find any major issues. Already looking forward to the next diff. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Validation ReportAll 21 validations passed. Show details
|
What does this PR do?
Runs the Argo Workflows Kind E2E with the Kubernetes Agent backend introduced by #24639.
workflow-controllerhas no backing Service, so the Agent (now running inside the Kind cluster) reaches it directly via the pod's IP address, fetched withkubectl get pods --namespace argo --selector app=workflow-controller --output json. The check now scrapeshttp://<pod-ip>:9090/metrics, so the external Docker Agent and thekubectl port-forwardtoworkflow-controllerare no longer needed.Validation:
ddev test -fs argo_workflowsddev --no-interactive test argo_workflows(3 passed, 1 E2E skipped)ddev env show argo_workflows(py3.13)ddev env start --dev argo_workflows py3.13ddev env test --dev argo_workflows py3.13(1 passed, 3 deselected)ddev env stop argo_workflows py3.13Motivation
This PR follows the conversion pattern from #24674 (argo_rollouts), adapted for a target with no Service: the pod IP is fetched directly, mirroring the approach used for Velero's
node-agentDaemonSet in #24645. Running the Agent inside the same Kind cluster removes the long-lived host-side port-forward without changing the E2E setup, waits, instance shape, or assertions.Review checklist (to be filled by reviewers)
qa/requiredif this PR needs QA validation, orqa/skip-qaif it does not. Exactly one of the two is required.backport/<branch-name>label to the PR and it will automatically open a backport PR once this one is merged