kubernetes/kops · error

cannot apply changes to Disk: %v

Error message

cannot apply changes to Disk: %v

What it means

After applying labels, RenderGCE checks whether any unhandled changes remain; if the changes struct is not DeepEqual to an empty Disk, the task cannot reconcile them and refuses to proceed rather than silently ignoring drift. This is a defensive guard in the GCE Disk task's apply logic.

Source

Thrown at upup/pkg/fi/cloudup/gcetasks/disk.go:170

		}
		// Danger: labels replace tags on instances; but thankfully volumes don't have tags
		//for _, k := range d.Tags {
		//	labelsRequest.Labels[k] = ""
		//}
		maps.Copy(labelsRequest.Labels, d.Labels)
		maps.Copy(labelsRequest.Labels, t.Cloud.Labels())
		maps.Copy(labelsRequest.Labels, e.Labels)
		klog.V(2).Infof("Setting labels on disk %q: %v", disk.Name, labelsRequest.Labels)
		if err = t.Cloud.Compute().Disks().SetLabels(t.Cloud.Project(), *e.Zone, disk.Name, labelsRequest); err != nil {
			return fmt.Errorf("error setting labels on created Disk: %v", err)
		}
		changes.Labels = nil
	}

	if a != nil && changes != nil {
		empty := &Disk{}
		if !reflect.DeepEqual(empty, changes) {
			return fmt.Errorf("cannot apply changes to Disk: %v", changes)
		}
	}

	return nil
}

type terraformDisk struct {
	Name                  *string           `cty:"name"`
	VolumeType            *string           `cty:"type"`
	SizeGB                *int64            `cty:"size"`
	ProvisionedIops       *int64            `cty:"provisioned_iops"`
	ProvisionedThroughput *int64            `cty:"provisioned_throughput"`
	Zone                  *string           `cty:"zone"`
	Labels                map[string]string `cty:"labels"`
}

func (*Disk) RenderTerraform(t *terraform.TerraformTarget, a, e, changes *Disk) error {
	cloud := t.Cloud.(gce.GCECloud)

View on GitHub (pinned to 4c8573c808)

Solutions

1. Read the %v of changes to see which field is unsupported
2. For immutable properties (size/type), delete and recreate the disk/instance group instead of updating in place
3. Remove the unsupported field from the cluster spec if unintended
4. File/fix a kOps bug if the field is new and lacks GCE apply support

// before apply, diff desired vs actual and fail on fields the GCE task can't update
unsupported := setDifference(desiredFields, handledFields) // e.g. size, type
if len(unsupported) > 0 { return fmt.Errorf("immutable fields need recreation: %v", unsupported) }

if err := render(...); err != nil {
  var changesErr *ChangesError
  if errors.As(err, &changesErr) { /* plan disk recreation instead of update */ }
}

When it happens

Trigger: An update to a Disk task produced changes fields that the earlier Insert/SetLabels code paths did not consume (e.g. a new field added to the Disk spec without corresponding apply logic, or fi.ComputeChanges returning fields RenderGCE doesn't handle).

Common situations: Upgrading kOps versions where a new Disk field is set in the cluster spec but the GCE task cannot update it in place; hand-edited cluster spec changing an immutable disk property (e.g. size/type) on an existing disk.

Related errors

• error during Disk creation: %v
• error reading created Disk: %v
• error setting labels on created Disk: %v
• creating gce IPAM controller: %w
• error building compute API client: %v

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