cilium/cilium · error

unmarkPool: %w

Error message

unmarkPool: %w

What it means

Thrown when unmarkPool fails. During conflict reconciliation, if a pool that was previously marked conflicting no longer conflicts, LB-IPAM calls unmarkPool to clear the CiliumPoolConflict condition (set to False with reason 'resolved'); the resulting status patch failure is wrapped as 'unmarkPool: %w'.

Source

Thrown at operator/pkg/lbipam/lbipam.go:1789

		}

		poolConflict := false
		for _, poolInner := range ipam.pools {
			if poolOuter.GetName() == poolInner.GetName() {
				continue
			}

			if conflicting, _, _ := areRangesConflicting(poolOuter.ranges, poolInner.ranges); conflicting {
				poolConflict = true
				break
			}
		}

		// The outer pool, which is marked conflicting no longer conflicts
		if !poolConflict {
			err := ipam.unmarkPool(ctx, poolOuter)
			if err != nil {
				return fmt.Errorf("unmarkPool: %w", err)
			}
		}
	}

	// Count the number of conflicting pools and update the metric.
	var conflictingPools float64
	for _, pool := range ipam.pools {
		// When a pool is marked as conflicting, all of its lbRanges are
		// internally disabled. Therefore, checking a single lbRange
		// is sufficient to conclude that the pool is conflicting.
		if len(pool.ranges) > 0 && pool.ranges[0].internallyDisabled {
			conflictingPools++
		}
	}

	ipam.metrics.ConflictingPools.Set(conflictingPools)

	return nil

View on GitHub (pinned to ac7b90affa)

Solutions

1. Inspect the wrapped error for the patch failure reason.
2. Ensure the operator can patch ciliumloadbalancerippools/status.
3. Check API server health and retry; the reconcile loop will re-run unmarkPool.
4. As a workaround, manually remove the stale condition with kubectl patch on the pool status.

Example fix

// manual workaround
kubectl patch ciliumloadbalancerippool <name> --subresource status --type json \
  -p '[{"op":"remove","path":"/status/conditions/0"}]'

if err := ipam.unmarkPool(ctx, poolOuter); err != nil {
    return fmt.Errorf("unmarkPool: %w", err) // retried on next reconcile
}

When it happens

Trigger: Reconciliation finds poolOuter marked conflicting but its ranges no longer overlap; the patch clearing the conflict condition on the pool status fails (API error, RBAC, resourceVersion conflict).

Common situations: An admin deleted/edited the overlapping pool so conflict resolved, but the API server is degraded or the operator lacks status patch permissions, so the stale 'conflicting' condition cannot be cleared.

Related errors

• markPoolConflicting: %w
• patchPoolStatus: %w
• unable to allocate health IPv4: %w, see https://cilium.link/
• unable to allocate health IPv6: %w, see https://cilium.link/
• cluster-pool-ipv4-cidr must be provided when using ClusterPo

AI-assisted analysis of cilium/cilium@ac7b90affa (2026-08-31). Data as JSON: /api/errors/747bb0c7740f6348. Report an issue: GitHub.