kubernetes/kops · error

error from apply: %w

Error message

error from apply: %w

What it means

ApplyOnce applies each expected object with client.Patch using types.ApplyPatchType (server-side apply). Any failure returned by the API server during that patch is wrapped as "error from apply: %w" and recorded for that object; the loop continues to the next object. The wrapped error is the API server's response, so the root cause lives inside the %w.

Source

Thrown at pkg/applylib/applyset/applyset.go:150

				NewManager: "kops",
				Client:     client,
			}
			if err := managedFields.Migrate(ctx, currentObj); err != nil {
				results.applyError(gvk, nn, err)
				continue
			}
		}

		j, err := json.Marshal(expectedObject)
		if err != nil {
			// TODO: Differentiate between server-fixable vs client-fixable errors?
			results.applyError(gvk, nn, fmt.Errorf("failed to marshal object to JSON: %w", err))
			continue
		}

		lastApplied, err := client.Patch(ctx, gvk, nn, types.ApplyPatchType, j, a.patchOptions)
		if err != nil {
			results.applyError(gvk, nn, fmt.Errorf("error from apply: %w", err))
			continue
		}

		tracker.lastApplied = lastApplied
		results.applySuccess(gvk, nn)
		tracker.isHealthy = isHealthy(lastApplied)
		results.reportHealth(gvk, nn, tracker.isHealthy)
	}
	return results, nil
}

View on GitHub (pinned to 4c8573c808)

Solutions

1. Read the wrapped error: for field-manager conflicts, re-apply with Force=true (patchOptions{FieldManager, Force}) or adopt/adjust the conflicting manager.
2. Ensure CRDs are applied before CRs — order expectedObjects so CRDs come first, or run apply twice.
3. Verify RBAC and kubeconfig connectivity to the target cluster (kubectl auth cani / kubectl get <resource>).
4. Retry the apply; applyset is designed to converge, so transient API errors often resolve on a subsequent run.

Example fix

// before
a := &Applyset{patchOptions: metav1.PatchOptions{FieldManager: "kops"}}
// after
a := &Applyset{patchOptions: metav1.PatchOptions{FieldManager: "kops", Force: ptr.To(true)}}

// preflight: ensure resource exists and caller can patch
mapping, err := restMapper.RESTMapping(gvk.GroupKind(), gvk.Version)
if err != nil { return err }
_ = mapping

err := applyset.ApplyOnce(ctx)
if err != nil {
    var apiErr *apierrors.StatusError
    if errors.As(err, &apiErr) && apierrors.IsConflict(err) {
        // enable Force or re-run apply to converge
    }
}

When it happens

Trigger: Server-side apply PATCH to the API server fails: conflicts with another field manager (Apply failed with conflicts), schema validation rejection, RBAC denial, connection errors, or the resource/GVK not existing on the server.

Common situations: Another controller owns fields with a different fieldManager and force is disabled; applying a CRD-backed resource before its CRD exists; the user's kubeconfig lacks permission on the target resource; kube-apiserver temporarily unreachable during cluster bring-up.

Related errors

• error patching object: %w
• error patching needs-update label: %v
• error querying namespace %q: %v
• error building annotation patch: %v
• error applying annotation to namespace: %v

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