Feature: Native SSA Support

[sbueringer]

Tasks:

• client.Apply: Server-side Apply! #347
  • ⚠ Client Server side apply  #2702
  • k/k: interface for ApplyConfigurations: Implement common interface in applyconfigs to make them identifiable as such kubernetes/kubernetes#118138
  • Support for Unstructured
• fake client support for SSA: Support server-side apply (client.Apply) in fake Client #2341
  • ✨ Fakeclient: Add apply support #2981
  • k/k: extend tracker: ManagedFieldsObjectTracker: Reload scheme kubernetes/kubernetes#132004

Tasks controller-tools:

• Generation of ApplyConfigurations: ✨ Generation of typed apply clients using upstream generator controller-tools#818
• Generation of Extract functions (details: Feature: Native SSA Support #3183 (comment))

[sbueringer]

cc @alvaroaleman @vincepri

[sbueringer]

cc @JoelSpeed

[shashankram]

@sbueringer Could you describe what's the gap with SSA in controller-runtime? I was under the impression SSA is already supported with Client.Patch(ctx, obj, client.Apply)

[alvaroaleman]

@sbueringer Could you describe what's the gap with SSA in controller-runtime? I was under the impression SSA is already supported with Client.Patch(ctx, obj, client.Apply)

Yep that works, but we want it to be a first-class citizen. Please see the initial issue for a list of missing things.

[shashankram]

@sbueringer Could you describe what's the gap with SSA in controller-runtime? I was under the impression SSA is already supported with Client.Patch(ctx, obj, client.Apply)

Yep that works, but we want it to be a first-class citizen. Please see the initial issue for a list of missing things.

I think I ran into a bug with SSA: #347 (comment)

Let me know if this is related to the issue being fixed.

[JoelSpeed]

One gap that we have is the extraction functions for the ApplyConfigurations, which require openapi.json to be able to generate.

The first step of which is to use kube-openapi to generate the openapi definitions as generated Go code.

This code is then imported into models-schema which then generated an openapi.json file, much like you could retrieve from a Kube API server.

This openapi.json is then fed into the OpenAPISchemaFilePath argument to the applyconfiguration gen, which allows it to generate the extraction functions.

I'd be interested to see if there was a way that we could combine the first two stages so that we don't have to output the intermediate generated go code, and could put the openapi.json file in a known location or even a temp location for creating the extract functions