kubernetes/kops · warning
reading actual user-data: %w
Error message
reading actual user-data: %w
What it means
During Scaleway instance reconciliation, kOps fetches the live 'cloud-init' user-data via the Scaleway instance API and reads its body into memory to hash-compare with the expected user-data. This error wraps any failure returned by io.ReadAll while draining the response reader (actualUserData). It means the API call succeeded (a reader was returned) but the streamed body could not be read, most often because the underlying HTTP body failed mid-transfer or the returned reader was in a bad state.
Source
Thrown at upup/pkg/fi/cloudup/scalewaytasks/instance.go:425
if actualServer.Image.ID != localImage.ID {
return true, nil
}
return false, nil
}
func checkUserDataDifferences(c *fi.CloudupContext, cloud scaleway.ScwCloud, actualServer *instance.Server, expectedUserData *fi.Resource) (bool, error) {
actualUserData, err := cloud.InstanceService().GetServerUserData(&instance.GetServerUserDataRequest{
Zone: actualServer.Zone,
ServerID: actualServer.ID,
Key: "cloud-init",
}, scw.WithContext(c.Context()))
if err != nil {
return false, fmt.Errorf("getting actual user-data: %w", err)
}
actualUserDataBytes, err := io.ReadAll(actualUserData)
if err != nil {
return false, fmt.Errorf("reading actual user-data: %w", err)
}
expectedUserDataBytes, err := fi.ResourceAsBytes(*expectedUserData)
if err != nil {
return false, fmt.Errorf("reading expected user-data: %w", err)
}
if sha256.Sum256(actualUserDataBytes) != sha256.Sum256(expectedUserDataBytes) {
return true, nil
}
return false, nil
}
func imageLabelFromID(c *fi.CloudupContext, cloud scaleway.ScwCloud, id string) (string, error) {
localImage, err := cloud.MarketplaceService().GetLocalImage(&marketplace.GetLocalImageRequest{
LocalImageID: id,
}, scw.WithContext(c.Context()))
if err != nil {
return "", fmt.Errorf("getting image from the marketplace: %w", err)View on GitHub (pinned to 4c8573c808)
Solutions
- Re-run `kops update cluster` — this read is usually transient and succeeds on retry.
- Verify network connectivity to api.scaleway.com (no proxy/VPN interference) and retry.
- Set a shorter cluster spec / retry with SCW API env defaults; check https://status.scaleway.com for API incidents.
- If persistent, delete/recreate user-data on the server or use `kops replace` to force refresh.
Example fix
// caller side retry instead of failing the whole reconcile
var actualUserDataBytes []byte
for attempt := 0; attempt < 3; attempt++ {
actualUserData, err := cloud.InstanceService().GetServerUserData(&instance.GetServerUserDataRequest{
Zone: actualServer.Zone, ServerID: actualServer.ID, Key: "cloud-init",
}, scw.WithContext(c.Context()))
if err != nil {
return false, fmt.Errorf("getting actual user-data: %w", err)
}
actualUserDataBytes, err = io.ReadAll(actualUserData)
if err == nil {
break
}
} Defensive patterns
Strategy: retry
Validate before calling
// ensure the server actually has cloud-init user-data before comparing
req := &instance.GetServerUserDataRequest{Zone: s.Zone, ServerID: s.ID, Key: "cloud-init"}
// callers should wrap GetServerUserData + ReadAll in a bounded retry with backoff
var data []byte
err := retry.Do(3, func() error {
r, err := cloud.InstanceService().GetServerUserData(req, scw.WithContext(ctx))
if err != nil { return err }
data, err = io.ReadAll(r)
return err
}) Try / catch
if actualBytes, err := io.ReadAll(actualUserData); err != nil {
return false, fmt.Errorf("reading actual user-data: %w", err) // retry at a higher level
} Prevention
- Retry transient read failures with exponential backoff instead of failing the reconcile
- Watch the Scaleway status page for API incidents before large applies
- Avoid running applies over unstable networks/proxies; prefer CI with reliable egress
When it happens
Trigger: io.ReadAll(actualUserData) fails after cloud.InstanceService().GetServerUserData(...) returned a reader for key 'cloud-init'; network interruption or TLS/reset while streaming the user-data body; server returns a truncated/aborted response body.
Common situations: Transient network failures or proxy timeouts during `kops update cluster` against Scaleway; flaky connectivity from CI runners; Scaleway API returning a connection reset mid-body; very large user-data payloads hitting intermediate timeouts.
Related errors
- reading expected user-data: %w
- reading primary MAC address from ec2 metadata: %w
- reading body %q: %w
- failed to read metadata information %s: %v
- listing IPs for deletion: %w
AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05).
Data as JSON: /api/errors/86604cbe76cc6fc7.
Report an issue: GitHub.