fix: exclude control plane endpoint from MetalMachine addresses#1605
fix: exclude control plane endpoint from MetalMachine addresses#1605scatat wants to merge 1 commit intosiderolabs:mainfrom
Conversation
👷 Deploy request for wonderful-swartz-a1308c pending review.Visit the deploys page to approve it
|
| addresses := make([]capiv1.MachineAddress, 0, len(serverBinding.Spec.Addresses)) | ||
| for _, addr := range serverBinding.Spec.Addresses { | ||
| // the control plane endpoint is shared, not per-machine | ||
| if addr == cluster.Spec.ControlPlaneEndpoint.Host { |
There was a problem hiding this comment.
I think this has same issue as CACPPT PR in general - this might break valid setups with single node controlplane.
There was a problem hiding this comment.
Good catch — fixed in f3d428b.
Added && len(serverBinding.Spec.Addresses) > 1 so the filter only fires when the machine has other addresses. Single-node CP where the endpoint is the only address keeps it.
There was a problem hiding this comment.
I still don't think it's correct, it's trying to guess something while the context is missing here.
Either it should be fixed on Talos side to stop reporting VIPs, or Sidero Metal should pull addresses itself.
When Talos reports node addresses, it includes the shared control plane endpoint (VIP). The metalmachine controller copies these into MetalMachine.Status.Addresses, where CACPPT treats them as per-machine endpoints, breaking scale-down operations. Filter the control plane endpoint at the CAPI boundary, guarded by len > 1 so single-node control planes retain the address. Ref: siderolabs/cluster-api-control-plane-provider-talos#242 Signed-off-by: scatat <stephentan@gmail.com>
scatat
force-pushed
the
fix/exclude-cp-endpoint-from-machine-addresses
branch
from
f3d428b to
c0e64a5
Compare
|
Squashed to a single commit with DCO sign-off. The GPG identity check will fail since I'm not in the siderolabs org — that one needs a maintainer override. |
4 participants
When Talos reports node addresses, it includes the shared control plane endpoint (e.g. a VIP). Sidero correctly stores these in
ServerBinding.Spec.Addresses. But when the MetalMachine controller copies them intoMetalMachine.Status.Addresses, the shared endpoint propagates toMachine.Status.Addresses, where CACPPT treats it as a per-machine Talos API endpoint. This breaks scale-down operations.This PR filters the control plane endpoint at the CAPI boundary in
metalmachine_controller.go, where theClusterobject is already in scope.ServerBindingretains the full address list.Safe when
ControlPlaneEndpoint.Hostis empty — comparison against""matches nothing, all addresses pass through.Ref: siderolabs/cluster-api-control-plane-provider-talos#242
🤖 Co-authored with AI