Add config discovery support to envoy#24562
Draft
martavicentenavarro wants to merge 6 commits into
Draft
Conversation
Adds a from_ports discovery strategy covering both the OpenMetrics and legacy stats_url dispatch modes on port 8001, regenerates config models, wires E2E discovery metadata, and adds discovery E2E tests.
🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: e156d2c | Docs | Datadog PR Page | Give us feedback! |
candidate_ports() yields every exposed port (hints only reorder), so the generated stats_url candidate was being probed against any port on the container, not just Envoy's admin port. The legacy check also calls /server_info before scraping /stats, risking hitting an unrelated upstream and misidentifying it as Envoy's admin endpoint.
InstanceConfig's field validator fills any unconfigured field with its default, so a strategy with more than one candidate (e.g. envoy's openmetrics_endpoint/stats_url pair) ended up with every candidate carrying a phantom default for the field it never set. That corrupted envoy's legacy-vs-modern dispatch, which keys off field presence. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…rride Codex review flagged that restricting stats_url to port 8001 means non-default admin ports won't be autodiscovered via the legacy path. Accepted as a known limitation for now, matching the integration's documented default admin port. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
8001 is the port used by this integration's test environment and discovery strategy hint, not an Envoy-documented default (upstream docs use 9901 as the example admin port). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Contributor
Validation ReportAll 21 validations passed. Show details
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Adds config discovery support to the Envoy integration: a
from_portsdiscovery strategy on port 8001 with two candidates covering both the OpenMetrics (openmetrics_endpoint) and legacy (stats_url) dispatch modes, regenerated config models,auto_conf.yaml,get_e2e_discovery_metadata()wiring in the E2E fixture, and newtest_e2e_discovery/test_e2e_discovery_all_candidatesE2E tests.Known limitation: the legacy
/statscandidate is restricted (viadiscovery_overrides.py) to the hinted admin port (8001), since probing arbitrary exposed ports with/server_info+/statsrisks misidentifying an unrelated upstream as Envoy's admin endpoint. Envoy deployments exposing the admin interface on a different port won't be discovered via the legacy path and still require a hand-written static config.openmetrics_endpointkeeps the default fallback across all candidate ports.Motivation
Part of the config discovery rollout (DSCVR-484). This is a fresh implementation built with the restructured
create-discovery-prskill, superseding #24121 which was built with the older version of the workflow.Related work: #24121 (older implementation) has been closed in favor of this PR.
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