Run Weaviate E2E with the Kubernetes Agent backend - #24830
Conversation
Switch from host-side kube_port_forward to the new Kubernetes Agent E2E backend: the API endpoint uses Service DNS, the metrics endpoint falls back to the pod IP since no Service targets that port, and the readiness check plus data-seeding POST now run from disposable in-cluster pods since the host can no longer reach the cluster directly. Environment: Datadog workspace Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
@codex review |
🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: 50e6399 | Docs | Datadog PR Page | Give us feedback! |
evalya-impact-summaryevalya impact analysis |
|
Codex Review: Didn't find any major issues. You're on a roll. 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". |
`/v1/.well-known/live` (DEFAULT_LIVENESS_ENDPOINT) is an unconditional 200 in Weaviate v1.20.0 with no actual readiness check, while the Pod `Ready` condition that `kubectl wait --for=condition=Ready` already blocks on is driven by the StatefulSet's readinessProbe (`/v1/.well-known/ready`, the real `DB.StartupComplete() && ClusterHealthScore() == 0` check). The extra busybox-based WaitFor poll was checking a strictly weaker signal than what setup_weaviate() already waits for, so it can't add any real confidence and was only burning disposable pods. Environment: Datadog workspace Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9102cc59b7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
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".
`run_command` defaults to `check=False`, so a timed-out or transient failure in the `kubectl create ns`/`apply`/`rollout status`/`wait` calls previously fell through silently into the pod-IP lookup and one-shot data-seeding curl, turning a clear "cluster never became Ready" failure into a confusing generic curl error. Add `check=True` to all four calls, matching the pattern already used for kuma's equivalent `setup_kuma()` (#24642). Environment: Datadog workspace Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
@codex review |
|
Codex Review: Didn't find any major issues. You're on a roll. 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 Weaviate Kind E2E with the Kubernetes Agent backend introduced by #24639.
weaviate_api_endpointnow uses the in-cluster Service DNS endpoint,http://weaviate.weaviate.svc.cluster.local:80, backed by theweaviateService (port: 80->targetPort: 8080).openmetrics_endpoint(port 2112) has no matching Service, so it falls back to the pod IP of the single-replicaweaviateStatefulSet, fetched viakubectl get pods -l app=weaviate.POSTto/v1/batch/objectspreviously ran on the host viarequests. It now runs from a disposablecurlimages/curlpod inside the cluster instead.ready_check(), hitting/v1/.well-known/livethrough akubectl port-forwardtunnel) has been removed rather than converted to an in-cluster equivalent./v1/.well-known/live(DEFAULT_LIVENESS_ENDPOINT, what the removed check polled) is an unconditional 200 with no real check behind it. The actual startup check lives behind/v1/.well-known/ready, which is exactly what the StatefulSet'sreadinessProbehits (seeweaviate_install.yaml), and the Kubernetes PodReadycondition is driven by the readiness probe, not the liveness probe. Sokubectl wait pods --for=condition=Ready, whichsetup_weaviate()already runs before seeding, provides a strictly stronger readiness guarantee than the removed poll ever did.setup_weaviate()'skubectlcalls (namespace/manifest creation, rollout status, readiness wait) now all passcheck=True, so a cluster that never becomes ready fails loudly there instead of surfacing as a confusing seed-request error further down.Motivation
https://datadoghq.atlassian.net/browse/DSCVR-659
This PR migrates Weaviate to the new backend, following the same pattern already applied to argo_rollouts (#24674) and calico (#24673), plus the pod-IP fallback pattern from velero (#24645) for the port with no Service.
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 mergedThis PR description was generated by Claude Code, on behalf of Vincent Whitchurch.