Code change:
The content of the file version showed in section is wrong. Previous versions where showing the right content, e.g. .
The one in the dev-1.26 branch is not a valid Deployment manifest. The API server will reject this YAML since it is missing some required fields.
Ah, the problem might be that we don't want a YAML file that is a valid Deployment manifest, since this is actually being used to generate a special document used for a with custom Kubernetes semantics. /kind bug I didn't actually know that would accept a thing that's not a valid manifest for ; that's going to be hard to teach / document. Is that even a supported / recommended way to do the change? (I can see that it works; whether it works is very different from whether we endorse it). I think this is a valid report. Maybe we should use an inline example rather than an external file; maybe we need a way to exempt this one YAML file from validation. If we use an inline example, that would mean changing we can keep would need to change.
If this YAML has to be an "invalid" Deployment manifest, using an inline example is more appropriate IMO.
I'll also ask SIG Architecture if this use of is one we endorse.
Exactly, this is one of the "tricks" behind SSA: you only provide (to the you indicate). Providing a fully compliant (from an schema pov) Deployment manifest would actually be a mistake if you only want to modify the field using SSA. Kubernetes client-go was updated to support these non-fully-conformant-from-an-schema-pov manifests: defining the new types for this to be possible as described in this .
/triage accepted /assign
OK, so the input to is no longer defined to be a manifest: it's actually an apply configuration, and all valid manifests are also valid apply configurations. However, defaults to validating that the supplied apply configuration is a valid manifest. You can then turn off that validation by using . Have I got that right? If so, I think we missed a key docs update when we made that change to / client-go. is the only mention of the term apply configuration on the Kubernetes site; the docs don't describe this at all. The rest of this comment assumes that the apply configuration concept does need documenting. I think we should clearly document which subcommands work with manifests and which with apply configurations. For example, I'd have to turn to the source code to answer which kind the subcommand expects, and that's not something an end user should need to be doing. A few subcommands and plugins to consider: - -
I also think we should track a new issue for to document the apply configuration concept, and leave this issue to cover the specific bug that reported.
is solving the reported fault (so properly closing this issue), thanks for it. I think there is still room for improvement in the "Transferring Ownership" example this issue is targeting (maybe to consider it in a future update of these pages?): For the "more advanced" case (the one targeted by this issue) it is proposed to use a partial manifest; used term here should be "fully specified intent" as it is the introduced term at the beginning of this same SSA doc. page to name these "shorter" yamls we can use with SSA. In the final is not needed, better to remove it to not confuse the reader.

Related discussion:
text: "nginx-svc":        {&api.Service{}}, }, "application/ssa": { <del> "nginx-deployment":               {&apps.Deployment{}}, "nginx-deployment-no-replicas":   {&apps.Deployment{}}, "nginx-deployment-replicas-only": {&apps.Deployment{}}, </del> <ins> "nginx-deployment":             {&apps.Deployment{}}, "nginx-deployment-no-replicas": {&apps.Deployment{}}, </ins> }, "application/web": { "web":          {&api.Service{}, &apps.StatefulSet{}},