autodiscovery: dedupe the fake krakend test server, drop ticket references

The two docker-compose e2e fixtures (fake-krakend, fake-krakend-conflict)
embedded byte-for-byte identical copies of a fake krakend metrics HTTP
server. Extract it into its own file (fake-krakend-server.py) and splice it
into both compose files via text/template -- the same pattern this package
already uses for Helm values (k8s_test.go's helmValuesTemplate) -- rather
than a docker-compose-native extends:/include: mechanism, which isn't used
anywhere else in this repo's e2e fixtures and would be an unverified first
use of that specific compose feature in this harness.

Verified both templates still render byte-for-byte identical (base fixture)
or with only the intended comment changes (conflict fixture) to the
pre-refactor files, and that the rendered YAML parses correctly.

Also drops the remaining Jira ticket references from this test file and the
conflict fixture's comments, and fixes a stale reference to a since-renamed
function (GenericIntegrationNamespaceRoots/NamespaceRoot).

Environment: Datadog workspace

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Author: vitkyrka

test/new-e2e/tests/discovery/config_discovery_linux_test.go

@@ -6,10 +6,12 @@
 package discovery
 
 import (
+	"bytes"
 	_ "embed"
 	"encoding/json"
 	"strings"
 	"testing"
+	"text/template"
 	"time"
 
 	"github.com/DataDog/datadog-agent/test/e2e-framework/components/datadog/dockeragentparams"
@@ -22,11 +24,49 @@ import (
 	awsdocker "github.com/DataDog/datadog-agent/test/e2e-framework/testing/provisioners/aws/docker"
 )
 
-//go:embed testdata/compose/docker-compose.fake-krakend.yaml
-var fakeKrakendComposeStr string
+// fakeKrakendServerScript is the fake krakend metrics HTTP server, shared
+// between the two compose fixtures below via text/template rather than
+// copy-pasted, since it's byte-for-byte identical in both.
+//
+//go:embed testdata/compose/fake-krakend-server.py
+var fakeKrakendServerScript string
+
+//go:embed testdata/compose/docker-compose.fake-krakend.yaml.tmpl
+var fakeKrakendComposeTmpl string
+
+//go:embed testdata/compose/docker-compose.fake-krakend-conflict.yaml.tmpl
+var fakeKrakendConflictComposeTmpl string
 
-//go:embed testdata/compose/docker-compose.fake-krakend-conflict.yaml
-var fakeKrakendConflictComposeStr string
+var fakeKrakendComposeStr = mustRenderFakeKrakendCompose(fakeKrakendComposeTmpl)
+
+var fakeKrakendConflictComposeStr = mustRenderFakeKrakendCompose(fakeKrakendConflictComposeTmpl)
+
+// mustRenderFakeKrakendCompose splices fakeKrakendServerScript into a compose
+// template's `{{.Script}}` placeholder, indented to match the surrounding
+// YAML block scalar. YAML literal block scalars (`|`) only require non-blank
+// lines to be indented at least as much as the block itself, so blank lines
+// are left alone.
+func mustRenderFakeKrakendCompose(tmplSrc string) string {
+	tmpl := template.Must(template.New("fake-krakend-compose").Parse(tmplSrc))
+	var buf bytes.Buffer
+	data := struct{ Script string }{Script: indentLines(fakeKrakendServerScript, 8)}
+	if err := tmpl.Execute(&buf, data); err != nil {
+		panic(err)
+	}
+	return buf.String()
+}
+
+func indentLines(s string, n int) string {
+	prefix := strings.Repeat(" ", n)
+	lines := strings.Split(strings.TrimRight(s, "\n"), "\n")
+	for i, line := range lines {
+		if line == "" {
+			continue
+		}
+		lines[i] = prefix + line
+	}
+	return strings.Join(lines, "\n")
+}
 
 type configDiscoverySuite struct {
 	e2e.BaseSuite[environments.DockerHost]
@@ -158,15 +198,14 @@ func (s *configDiscoverySuite) verifyKrakendCheckProvider(c *assert.CollectT) {
 }
 
 // TestKrakendConfigDiscoverySuppressedByConflictingGenericIntegration verifies
-// the DSCVR-626 fix: configuration discovery must not schedule a second,
-// duplicate check on a container that already has a manually-configured
-// generic openmetrics/prometheus check claiming the same (or a rooted-in)
-// metric namespace as the dedicated integration would use. Without the fix,
-// both krakend (via discovery) and the manual openmetrics config would run
+// that configuration discovery must not schedule a second, duplicate check on
+// a container that already has a manually-configured generic
+// openmetrics/prometheus check claiming the same (or a rooted-in) metric
+// namespace as the dedicated integration would use. Without this, both
+// krakend (via discovery) and the manual openmetrics config would run
 // concurrently against the fake-krakend-conflict container, double-collecting
 // (and, for counter metrics, doubling the reported value of) the same
-// metrics — see https://datadoghq.atlassian.net/browse/DSCVR-626 for the
-// underlying bug and its real-world impact.
+// metrics.
 //
 // fake-krakend-conflict is a second, independent container from
 // fake-krakend (used by TestKrakendConfigDiscovery): it's also image-matched

test/new-e2e/tests/discovery/testdata/compose/docker-compose.fake-krakend-conflict.yaml

@@ -0,0 +1,51 @@
+services:
+  fake-krakend-conflict:
+    container_name: fake-krakend-conflict
+    # Built and tagged as image "krakend" (rather than using the
+    # com.datadoghq.ad.check.id override label like docker-compose.fake-krakend.yaml)
+    # so that this container's own entity ID *also* remains among its AD
+    # identifiers -- needed so the manual com.datadoghq.ad.checks openmetrics
+    # config below (matched by entity ID) is a sibling of krakend's
+    # image-matched discovery template on the exact same service, reproducing
+    # the scenario where a manual openmetrics config and a later-discovered
+    # dedicated integration both target the same container.
+    image: krakend:e2e-conflict-test
+    build:
+      context: .
+      args:
+        DD_REGISTRY: ${DD_REGISTRY:-docker.io}
+        # see docker-compose.fake-process.yaml for why this needs double-escaping
+      dockerfile_inline: |
+        ARG DD_REGISTRY=docker.io
+        FROM $${DD_REGISTRY}/library/python:3.12-slim
+    command:
+      - sh
+      - -c
+      - |
+        python3 << 'EOF'
+{{.Script}}
+        EOF
+    labels:
+      # A manual openmetrics config, as a user might configure for a service
+      # that doesn't (yet) have a dedicated Datadog integration. Its namespace
+      # ("krakend.api") is rooted in krakend's own metric namespace
+      # (__NAMESPACE__ = "krakend.api" in datadog_checks/krakend/check.py), so
+      # once krakend's configuration-discovery template matches this same
+      # container, discovery must be suppressed (see
+      # comp/core/autodiscovery/listeners/common_filter.go's
+      # GenericIntegrationNamespaceRoots/NamespaceRoot).
+      com.datadoghq.ad.checks: |
+        {
+          "openmetrics": {
+            "init_config": {},
+            "instances": [
+              {
+                "openmetrics_endpoint": "http://%%host%%:9091/metrics",
+                "namespace": "krakend.api"
+              }
+            ]
+          }
+        }
+    expose:
+      - "9090"
+      - "9091"

test/new-e2e/tests/discovery/testdata/compose/docker-compose.fake-krakend-conflict.yaml.tmpl

@@ -0,0 +1,20 @@
+services:
+  fake-krakend:
+    container_name: fake-krakend
+    # python:3.12-slim is already pulled by the mutatedbyadmissioncontroller
+    # k8s e2e test (test/e2e-framework/components/datadog/apps/mutatedbyadmissioncontroller/k8s.go)
+    # through the same ${DD_REGISTRY}/dockerhub/library/python ECR pull-through
+    # cache path, so reusing it here avoids warming the cache for a new tag.
+    image: ${DD_REGISTRY:-docker.io}/library/python:3.12-slim
+    command:
+      - sh
+      - -c
+      - |
+        python3 << 'EOF'
+{{.Script}}
+        EOF
+    labels:
+      com.datadoghq.ad.check.id: krakend
+    expose:
+      - "9090"
+      - "9091"

test/new-e2e/tests/discovery/testdata/compose/docker-compose.fake-krakend.yaml

@@ -0,0 +1,53 @@
+import http.server
+import socketserver
+import threading
+
+
+class MetricsHandler(http.server.BaseHTTPRequestHandler):
+    # The real krakend metrics endpoint. Deliberately NOT on 9090 (see
+    # below) so that the test proves discover_config actually probes
+    # and picks the right port among several exposed ones, rather
+    # than trivially succeeding because there's only one candidate.
+    BODY = (
+        b"# HELP krakend_requests_total Total requests.\n"
+        b"# TYPE krakend_requests_total counter\n"
+        b"krakend_requests_total 42\n"
+        b"# HELP go_goroutines Number of goroutines.\n"
+        b"# TYPE go_goroutines gauge\n"
+        b"go_goroutines 17\n"
+    )
+
+    def do_GET(self):
+        self.send_response(200)
+        self.send_header("Content-Type", "text/plain; version=0.0.4; charset=utf-8")
+        self.send_header("Content-Length", str(len(self.BODY)))
+        self.end_headers()
+        self.wfile.write(self.BODY)
+
+    def log_message(self, *args):
+        pass
+
+
+class DummyHandler(http.server.BaseHTTPRequestHandler):
+    # A decoy endpoint on krakend's default metrics port (9090) that
+    # is NOT valid krakend/openmetrics output. If config discovery
+    # picked a port blindly instead of probing and validating each
+    # candidate, it would pick this one and the test would fail.
+    BODY = b"not krakend metrics\n"
+
+    def do_GET(self):
+        self.send_response(200)
+        self.send_header("Content-Type", "text/plain; charset=utf-8")
+        self.send_header("Content-Length", str(len(self.BODY)))
+        self.end_headers()
+        self.wfile.write(self.BODY)
+
+    def log_message(self, *args):
+        pass
+
+
+threading.Thread(
+    target=lambda: socketserver.TCPServer(("", 9090), DummyHandler).serve_forever(),
+    daemon=True,
+).start()
+socketserver.TCPServer(("", 9091), MetricsHandler).serve_forever()