kubernetes/kops · error

error patching Subnet: %w

Error message

error patching Subnet: %w

What it means

Wrapped error from updateSecondaryRanges when the Subnetworks.Patch call (applying secondary-range add/remove changes) fails synchronously. The %w carries the GCE rejection — commonly a range-name conflict or overlapping CIDR in secondary ranges.

Source

Thrown at upup/pkg/fi/cloudup/gcetasks/subnet.go:242

			}
		}

		if !patch {
			return nil
		}

		subnet.SecondaryIpRanges = nil
		for k, v := range expectedRanges {
			subnet.SecondaryIpRanges = append(subnet.SecondaryIpRanges, &compute.SubnetworkSecondaryRange{
				RangeName:   k,
				IpCidrRange: v,
			})
		}
	}

	patchOp, err := cloud.Compute().Subnetworks().Patch(cloud.Project(), cloud.Region(), subnet.Name, subnet)
	if err != nil {
		return fmt.Errorf("error patching Subnet: %w", err)
	}

	if err := cloud.WaitForOp(patchOp); err != nil {
		return fmt.Errorf("error waiting for Subnet patch to complete: %w", err)
	}

	return nil
}

func updateStackTypeAndIPv6AccessType(cloud gce.GCECloud, e *Subnet) error {
	// We need to refetch to patch it
	subnet, err := cloud.Compute().Subnetworks().Get(cloud.Project(), cloud.Region(), *e.Name)
	if err != nil {
		return fmt.Errorf("error fetching subnet for patch: %w", err)
	}

	subnet.StackType = fi.ValueOf(e.StackType)
	subnet.Ipv6AccessType = fi.ValueOf(e.Ipv6AccessType)

View on GitHub (pinned to 4c8573c808)

Solutions

  1. Inspect the wrapped error for the exact rejection reason
  2. Ensure secondary range names and CIDRs don't conflict with existing ranges on the subnet
  3. Fix the spec and re-run the apply
Defensive patterns

Strategy: try-catch

When it happens

Trigger: Thrown at upup/pkg/fi/cloudup/gcetasks/subnet.go:242 when the library encounters an invalid state.

Common situations: See trigger scenarios.


AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05). Data as JSON: /api/errors/b2a1ba56e74ff26a. Report an issue: GitHub.