Consider deprecating configurations field

[KnVerey]

The configurations field is an old, pre-plugin, pre-openapi global configuration mechanism for custom resources. Since we're aiming to make the openapi field the blessed way of getting custom resource support (see also #3944), we should consider removing all legacy ways to do the same thing, to simplify user experience and maintenance.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[natasha41575]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[KnVerey]

/lifecycle frozen

[kferrone]

I have been unable to successfully use the crds or openapi plugins with kustomize. So far, if I need kustomize to handle name references in custom resources, then the configurations just work. However it is extremely tedious to have this on every kustomization file. Can there just be one file next to the plugins like $XDG_CONFIG_HOME/kustomize/konfig.yaml. Then kustomize would just globally work with custom stuff. Every other option provided all intend to be inside every single kustomization as a plugin. I also dream of being able to use these configurations within custom plugins I wrote.

[KnVerey]

Thanks for the input, @kferrone. Can you please provide more detail on the challenges you're encountering in switching from configurations to openapi?

However it is extremely tedious to have this on every kustomization file.

Do you mean within a given configuration tree (i.e. in both bases and overlays) or across multiple apps? For both configurations and openapi, you should only need to include it in the top layer. I understand that even this can be tedious when you manage many config sets, but as a rule we want to keep Kustomize's configuration 100% declarative, which means including everything that can affect output in the Kustomization resource.

I also dream of being able to use these configurations within custom plugins I wrote.

I spoke with @natasha41575 about this, and apparently there has been some discussion in the past about passing openapi data declaratively through the KRM Functions specification. It hasn't been implemented so far, but it is useful for us to hear the feedback that this is a desired feature. I've created an issue here: #4351

[kferrone]

@KnVerey

Do you mean within a given configuration tree (i.e. in both bases and overlays) or across multiple apps?
I mean across many git repos with directories representing many apps.
I also deal with a ton of operators creating loads of CRD resources in our clusters.

I haven't had any success using the openapi feature. I followed this guide:
kustomization openapi

I ran this command: kustomize openapi fetch > schema.json which created an extremely large file. I added things like x-kubernetes-patch-strategy. PatchStrategicMerge and renaming still doesn't work for me. Not exactly sure what went wrong? The guide is pretty straight forward.

I end up falling back to using the configurations field in a Component and referencing the component in every app which needs it.
like this:

components:
- ../../../konfig

Sounds like the only change would be simply to switch to using:

openapi:
  path: ../../../konfig/schema.json

Taken the schema file itself doesn't literally need to be in the same directory. Would I be able to put this giant schema.json in a git repo and reference remotely?

Ultimately I simply have not been successful with the OpenApi stuff yet. I haven't experimented enough either. When I did follow the guide I just didn't get the desired strategic merge effect with the array or name prefixing. Kustomize gave me no complaints either. So not really sure what I'm doing wrong here, seems like more docs and more examples would generally help a lot here.

I'm also curious about what is actually deprecating here. Just the configurations field in a kustomization.yaml or the whole current strategy for referencing including all of the fieldSpecs within the individual plugins?
Basically, will a plugin like this with fieldSpecs still be a thing?

apiVersion: builtin
kind: LabelTransformer
metadata:
  name: not-important-to-example
labels:
  app: myApp
  env: production
fieldSpecs:
- path: metadata/labels
  create: true

Or will kustomize in the background start fully using the openapi stuff as the main strategy and fieldSpecs deprecate as well?

[KnVerey]

Taken the schema file itself doesn't literally need to be in the same directory. Would I be able to put this giant schema.json in a git repo and reference remotely?

That sounds like a reasonable request to me.

@natasha41575 has been thinking about this, and has decided to tackle this issue, #3944 and #3418 holistically. She will be preparing KEP with a detailed plan for the way forward, including migration path for all three existing ways of doing things. Whether or not fieldSpecs continue to be the way to configure individual built-in transformers is a great question that KEP will need to address.

[ncapps]

Adding a note that the skip: true field is not documented or well-understood. It appears to be a common source of confusion as noted on #5272. We will need to address this if we keep the configuration field.

[wmiller112]

Has the skip field been fully removed? I still cant seem to find any reference to it, but had some instances where it was previously working and after updating kustomize seems to no longer work. I understand the alternative is to add every resource type that should be prefixed/suffixed to a configuration specifying those types, but that seems unnecessarily complex when it seems I've come across a few issues where people are looking to leave out a single resource type from the operation.
Edit: Looks like it's likely due to this PR if not fully removed intentionally elsewhere