kubernetes/kops · error

updating volume %s (%s): %w

Error message

updating volume %s (%s): %w

What it means

kOps wraps errors from the Scaleway instance API when updating an existing volume in the volume task's RenderScw. The wrapped error comes from scaleway-sdk-go's instanceService.UpdateVolume call, so it means the API rejected the update (wrong volume ID, state conflict, or API/auth failure). kOps preserves the volume name and ID for identification.

Source

Thrown at upup/pkg/fi/cloudup/scalewaytasks/volume.go:119

		}
	}
	return nil
}

func (_ *Volume) RenderScw(t *scaleway.ScwAPITarget, actual, expected, changes *Volume) error {
	instanceService := t.Cloud.InstanceService()
	zone := scw.Zone(fi.ValueOf(expected.Zone))

	if actual != nil {
		_, err := instanceService.UpdateVolume(&instance.UpdateVolumeRequest{
			Zone:     zone,
			VolumeID: fi.ValueOf(actual.ID),
			Name:     expected.Name,
			Tags:     new(expected.Tags),
			Size:     scw.SizePtr(scw.Size(fi.ValueOf(expected.Size))),
		})
		if err != nil {
			return fmt.Errorf("updating volume %s (%s): %w", *actual.Name, *actual.ID, err)
		}

	} else {
		_, err := instanceService.CreateVolume(&instance.CreateVolumeRequest{
			Zone:       zone,
			Name:       fi.ValueOf(expected.Name),
			VolumeType: instance.VolumeVolumeType(fi.ValueOf(expected.Type)),
			Size:       scw.SizePtr(scw.Size(fi.ValueOf(expected.Size))),
			Tags:       expected.Tags,
		})
		if err != nil {
			return fmt.Errorf("rendering volume: %w", err)
		}
	}

	return nil
}

View on GitHub (pinned to 4c8573c808)

Solutions

  1. Check the wrapped SDK error: if it says the volume cannot be shrunk, only increase the volume size in the cluster spec, never decrease.
  2. Verify the volume still exists in the Scaleway console in the same zone as the cluster; re-add it or re-run `kops update cluster` if it was deleted out-of-band.
  3. Confirm SCALEWAY_ACCESS_KEY/SECRET_KEY/PROJECT credentials are valid and have Instance API permissions.
  4. Retry the update if the wrapped error indicates a transient 429/5xx Scaleway API failure.

Example fix

// before: shrinking volume in cluster spec
volumeSize: 100
volumeSize: 50
// after: keep or grow the size (shrink is unsupported)
volumeSize: 100
Defensive patterns

Strategy: validation

Validate before calling

// before applying, ensure the volume change is legal
if desired.Size != nil && actual.Size != nil && *desired.Size < *actual.Size {
    return fmt.Errorf("volume %s cannot shrink from %d to %d GB", *actual.Name, *actual.Size, *desired.Size)
}
// also confirm the volume still exists via the Scaleway API before updating

Try / catch

if err != nil {
    var apiErr *sdk.Error
    if errors.As(err, &apiErr) && apiErr.StatusCode == 429 {
        // backoff and retry the update
    }
    return fmt.Errorf("updating volume %s (%s): %w", name, id, err)
}

Prevention

When it happens

Trigger: RenderScw runs during `kops update cluster` on a Scaleway cluster; the volume exists (actual.VolumeID matches), the update diff is non-empty (name/tags/size changed), and instanceService.UpdateVolume returns an error — e.g. volume attached and size shrink attempted, deleted volume, or SDK/network failure.

Common situations: Shrinking a root/data volume (Scaleway volumes cannot be shrunk); volume deleted out-of-band in the Scaleway console; expired or missing Scaleway credentials; transient Scaleway API outage; changing volume type in place which the API rejects.

Related errors


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