Skip to content

charts/redpanda, multicluster: share listener and truststore rendering - #1923

Draft
chrisseto wants to merge 1 commit into
chris/dedup-rbacfrom
chris/dedup-listeners
Draft

chrisseto wants to merge 1 commit into
chris/dedup-rbacfrom
chris/dedup-listeners

Conversation

@chrisseto

Copy link
Copy Markdown
Contributor

The chart and the stretch-cluster renderer each carried a full copy of listener resolution: what Redpanda binds, what Kubernetes exposes, which certificate each endpoint serves, and which truststore it trusts. PKI stopped short of truststores because one belongs to a listener, not a certificate; this is what unblocks that.

charts/redpanda/listeners.go is now the single IR. An APIKind enum keys it and derives every redpanda.yaml key an API renders under; Listeners maps kind to API, and the four traversal orders -- config, truststores, ports, gateways -- are []APIKind. They disagree, deliberately, and each is pinned to rendered output. Listener TLS resolves against the shared PKI, so a keypair is named once. Both renderers translate their own values into the IR once per render (resolveListeners) and render from it.

Not output neutral:

  • rpc_server_tls.truststore_file was written but the file was never projected. RPC now takes part in truststore projection like any other listener.
  • Service ports carry appProtocol and an explicit targetPort. The old gateway/NodePort paths emitted targetPort: 0, which the API server defaulted to port, so this is inert on the cluster but visible in goldens.
  • <api>_tls: null is no longer emitted for an API serving no TLS.

@chrisseto
chrisseto added this pull request to stack #1882 September 25, 2026 19:34
@secpanda

secpanda commented Sep 25, 2026 •

Copy link
Copy Markdown

✅ Snyk checks have passed. No issues have been found so far.

Status Scan Engine Critical High Medium Low Total (0)
✅ Open Source Security 0 0 0 0 0 issues
✅ Licenses 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

@chrisseto
chrisseto force-pushed the chris/dedup-listeners branch from 1e4ea0e to 638893e Compare September 25, 2026 19:59
@chrisseto
chrisseto force-pushed the chris/dedup-listeners branch 2 times, most recently from 4aeef8b to 2b96f5a Compare September 30, 2026 20:30
@github-actions

github-actions Bot commented Oct 6, 2026

Copy link
Copy Markdown

This PR is stale because it has been open 5 days with no activity. Remove stale label or comment or this will be closed in 5 days.

@github-actions github-actions Bot added the stale label Oct 6, 2026
@chrisseto chrisseto removed the stale label Oct 6, 2026
The chart and the stretch-cluster renderer each carried a full copy of
listener resolution: what Redpanda binds, what Kubernetes exposes, which
certificate each endpoint serves, and which truststore it trusts. `PKI`
stopped short of truststores because one belongs to a listener, not a
certificate; this is what unblocks that.

`charts/redpanda/listeners.go` is now the single IR. An `APIKind` enum keys
it and derives every redpanda.yaml key an API renders under; `Listeners` maps
kind to `API`, and the four traversal orders -- config, truststores, ports,
gateways -- are `[]APIKind`. They disagree, deliberately, and each is pinned
to rendered output. Listener TLS resolves against the shared `PKI`, so a
keypair is named once. Both renderers translate their own values into the IR
once per render (`resolveListeners`) and render from it.

Not output neutral:
- `rpc_server_tls.truststore_file` was written but the file was never
  projected. RPC now takes part in truststore projection like any other
  listener.
- Service ports carry `appProtocol` and an explicit `targetPort`. The old
  gateway/NodePort paths emitted `targetPort: 0`, which the API server
  defaulted to `port`, so this is inert on the cluster but visible in goldens.
- `<api>_tls: null` is no longer emitted for an API serving no TLS.
@chrisseto
chrisseto force-pushed the chris/dedup-listeners branch from 2b96f5a to 43ebff4 Compare October 9, 2026 17:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants