You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit ffe54ad
Browse filesBrowse the repository at this point in the historyBrowse files
fix(site-router): close five defects from an independent review pass
None of these overlap the previous round.
DataVolume.spec is immutable in CDI, and the appliance digest moves on every
release because the image package stays in the root Makefile build: list. So
`helm upgrade` on an installed instance rendered a new source under the same
`<release>-boot` name, which is an update to an immutable spec. Every release
would have broken every installed site-router. The chart now re-emits the
live DataVolume's spec verbatim, the way packages/apps/vm-disk already does
for the same reason (#2985, docs/storage-immutability.md).
Preserving is silent for the digest and loud for storageClass, deliberately.
The digest is a platform stamp, so failing the render on it would swap a
broken upgrade for a blocked one, and the lifecycle this chart documents
already says a running gateway keeps the appliance it was created with.
storageClass is operator input, so a change that would silently not happen
fails instead — which also answers the immutability caveat raised against
this field in the previous round.
programNamespaceRoutes recorded the new gateway IP before writing the
entries that IP claims. The routes annotation is shared across the
namespace, and that record is the only way a later reconcile tells this
gateway's entries from a co-tenant's; mergeRoutes needs both the current and
previous IP to migrate them. A failure between the two writes left the old
entry looking foreign, so mergeRoutes returned RouteConflict forever and
reconcileDelete could not identify it either. The record now follows the
write, which fails safe: a crash in the new window just migrates the same
entries again.
renderTunnelIngressFilter degraded an empty destination set to a source-only
accept. A jumped-chain accept is a terminal verdict, so that forwards a
valid-source packet to any destination including the internet, which is the
exact hole the destination constraint exists to be. The guard against
reaching it was a comment asserting the controller could never resolve an
empty set on a pushing path, and it could: the set is this namespace's live
Pod IPs and Service ClusterIPs, and in a namespace holding only the gateway,
the tunnel Service disappearing between the LoadBalancer read and the
Service list empties it. Empty now emits no new-flow accept at all, and the
controller records a Warning so a tunnel that forwards nothing says why.
build-vyos had no fork path. The registry login above it is correctly
skipped on a fork, but nothing took its place, so PUSH stayed on and a fork
PR touching the appliance pushed with a read-only token and took finalize
and e2e down with it. It exports to an OCI archive like every other image
job, under the pr-oci-* name e2e-fork.yaml globs for.
The negative-security e2e asserted Cilium POLICY_DENIED for a foreign tenant
pod and for the kubernetes API ClusterIP. Those comments describe rules
admitting the whole pod and service CIDRs; the implementation admits one /32
per Pod IP and ClusterIP owned by this namespace, so both packets die at the
guest and never reach the veth where Cilium enforces. The assertions failed
because the isolation is stronger than they assumed. They assert the guest
counter now, and hubble_dropped says why it has no caller left.
Assisted-By: LLM
Signed-off-by: Myasnikov Daniil <[email protected]>
"no Pod IP or Service ClusterIP resolved in this namespace, so the gateway accepts no new decrypted flows; this clears itself once the tunnel Service and the tenant's workloads are present")
0 commit comments