Repository navigation
feat: index HTTPProxy hostnames and backends - #307
Merged
Merged
Conversation
Support and customers look for a load balancer by the hostname they see in a browser or a ticket, not by its resource name. The search index for HTTPProxy only covers the name, namespace and a few annotations, so a search for a datumproxy.net hostname, a custom domain, an origin endpoint or a connector returns nothing. Make those values searchable: the canonical hostname, the customer hostnames in spec and status, the programmed addresses, the rule names, the backend endpoint, connector and instance names, and the owner reference name. Store the creation timestamp and condition type and status without making them searchable so results can be filtered and sorted on them. The array paths were already written but commented out because the policy validator rejected [*] traversal (milo-os/search#97). That was fixed in milo-os/search#100 and shipped in v0.7.0, and production runs v0.8.4, so the paths are valid now. A ReindexJob for HTTPProxy is required after rollout. Documents frozen at create time do not pick up the canonical hostname until the indexer ordering fix lands, so status-derived results are partial until then.
JoseSzycho
approved these changes
Oct 14, 2026
4 tasks done
scotwells
added a commit
that referenced
this pull request
Oct 14, 2026
Support can now find a domain by the nameservers it delegates to, an export policy by the sources, sinks or remote-write endpoint it carries, and a workload by where it runs or what image it ships. Those fields were already drafted in the three search index policies but disabled while the policy validator rejected array paths, so searches for anything beyond a resource name and its annotations came back empty. That limitation was lifted in search v0.7.0 and production runs v0.8.4, so this change simply turns the drafted paths on, corrects one that pointed at a field the API never had, and stores condition state so results can show health at a glance. It is the same unlock already applied to load balancers in #307. ## What changed Domain, searchable: nameserver hostnames. Stored: condition type and status. ExportPolicy, searchable: source names, sink names, and the Prometheus remote-write endpoint (the drafted `.spec.sinks[*].endpoint` path does not exist; the endpoint lives under `.spec.sinks[*].target.prometheusRemoteWrite`). Workload, searchable: placement names, city codes and location names, the runtime class, and sandbox container images. Stored: condition type and status. The stale note about unsupported array traversal is removed from all three. Existing name, namespace, annotation and replica fields are unchanged. ## Test plan - [x] Rendered the search component with kustomize through a wrapper Kustomization; all seven policies build, with 11, 7 and 14 fields on Domain, ExportPolicy and Workload, and every entry carries only `path` and `searchable` with boolean values - [x] Checked every new path against the current API types: Domain in network-services-operator, ExportPolicy in milo-os/telemetry, Workload and Instance in datum-cloud/compute - [ ] Staging: the search controller reports each policy Ready and a search for a known nameserver, sink endpoint and city code returns the owning resource after reindex - [ ] Create a ReindexJob for Domain, ExportPolicy and Workload after rollout; existing documents do not pick up the new fields on their own
This was referenced Oct 14, 2026
scotwells
added a commit
that referenced
this pull request
Oct 14, 2026
Support can now find a load balancer by the network service it sends traffic to, which is how every compute-backed load balancer names its backend. The earlier change in #307 made connector and instance backend names searchable but left the network service name out, so a search for the service behind a compute-backed load balancer returned nothing. This adds that one field. Nothing else in the policy changes. ## What changed HTTPProxy, searchable: `.spec.rules[*].backends[*].networkService.name`. ## Test plan - [x] Rendered the search component with kustomize through a wrapper Kustomization; the HTTPProxy policy builds with the new field - [x] Checked the path against the HTTPProxy API type in network-services-operator (`backends[].networkService.name`) - [ ] Staging: a search for a network service name returns the load balancers that use it - [ ] No reindex expected, since Meilisearch re-indexed stored documents on the previous searchable-attribute change; confirm the same here
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
2 participants
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.
Support and customers can now find a load balancer by the hostname they actually see: its datumproxy.net hostname, a custom domain, an origin endpoint, or the connector or instance it routes to. Until now the search index only knew a load balancer by its resource name and a few annotations, so a hostname pasted from a ticket or a browser returned nothing. The array paths were already drafted in the policy but disabled because the policy validator did not accept array traversal; that limitation was lifted in search v0.7.0 and production runs v0.8.4. This change turns those paths on and adds the status-derived hostnames and addresses alongside them.
Status-derived values depend on a separate indexer ordering fix (documents frozen at create time never gain the canonical hostname), so hostname results will be partial until that lands. This policy may later move to the network-services-operator repo once a delivery path for its milo config exists.
What changed
Searchable:
Stored, not searchable (for filtering and sorting):
The existing name, namespace and annotation fields are unchanged. The stale note about unsupported array traversal is removed.
Test plan
pathandsearchableFieldPolicytype, and every HTTPProxy path against the network-services-operator v0.27.0 API types