Pod Presets still in alpha since v1.6, time to remove it?

[dims]

• https://kubernetes.io/docs/concepts/workloads/pods/podpreset/
• [Service Catalog]: Pod Preset enhancements#162

There was an effort at one point to promote it to Beta kubernetes/enhancements#348

This may have moved to Service Catalog repo https://github.com/kubernetes-sigs/service-catalog/search?q=podpreset&type=Commits

So question, do we remove it from kubernetes/kubernetes ?

[dims]

/sig apps
/sig service-catalog

@pmorie @duglin Thoughts please!

[liggitt]

I see removal of perma-alpha APIs as a natural next step after the "prevent perma-beta" work to put end dates on beta APIs

[mszostok]

The PodPreset functionality is not used in Service Catalog, we have an issue to remove references to it in the svc-cat repo, see: kubernetes-retired/service-catalog#2637

In the separate issue, we will figure out how to implement the e2e functionality for injecting secrets into an application: kubernetes-retired/service-catalog#2638

IMO it's ok to remove it as right now there is no decision about how to use it in svc-cat and currently we do not have enough capacity to work on that.

In Kyma project we build an abstraction on top of PodPreset but we also forked PodPreset to our org.

/cc @jberkhahn

[devlounge]

Many of us have been waiting for this to become mature since along time.
Removing PodPresets would be quite sad, as it would allow many people to stop having to write their own mutating webhooks for things PodPresets could do really well.
Also I had in mind to use it for automatically mounting common volumes into pods and much more.

[whereisaaron]

Me too @devlounge. Doing my usual check of has-this-thing-got-to-beta-so-I-can-finally-use-it only to find PodPresets had entirely disappeared 😞

This feature was going to greatly simplify our manifests. We do have the mutating webhooks feature now, which we didn't when PodPresets were created. However PodPresets are a lot cleaner would have received a lot of use. Even helm chart designs could be greatly simplified with optional PodPreset manifests. So I was looking forward to getting them available for use.

Things in alpha can never gain traction or significant interest because managed providers won't let you enable them. This is not really a case of 'perma-beta'. But, if they were not going anywhere then I can understand removing them.

[whereisaaron]

Speaking of gaining traction and momentum, the 'Avoiding permanent beta' policy only has a nine-month countdown for beta features. This new policy clashes with the recent popularity of managed releases, which tend to lag upstream releases by 6-9 months (2-3 releases).

E.g. the current AWS EKS lag for k8s release calendar is 6-9 months. That is before users can start planning upgrades in the 3-6 months after that. So a brand-spanking new beta feature won't reach cloud provider users until 9-15 months after it reaches beta upstream. Then users will start trying it out, and if it works well and get some interest and momentum behind it, only to find it has been already removed from a subsequent releases because of the mandatory 9-month policy 😄 In practice AWS probably won't enable a beta feature that is already removed upstream, so we can basically expect beta features will never reach, or get a chance for real-world feedback from cloud provider users.

It is going to be tough for contributors to get 'evidence in real-world use' when the real world can't test a release with a beta feature until after it has already hit mandatory removal 🤔

The motivation here seems pretty clear: get features stable. Guaranteeing that beta features will be deprecated adds a pretty big incentive so that people who want the feature continue their effort until the code, documentation and tests are ready for this feature to graduate to stable, backed by several Kubernetes' releases of evidence in real-world use.

[neolit123]

For long running alpha features I usually recommend announcing depreaction and removing after one release, instead of right away. For extending the beta policy please see: #94694.

[justinfx]

Please don't remove this feature! We only just discovered it this week and it was positioned to solve a real issue with common volume specs, in the same way mentioned by @devlounge
It would be really sad to now see it removed when it was going to fix some integration issues for us!

[lewisdiamond]

Could you elaborate on why PodPresets were never promoted to beta and why you want to remove them now? It seems like a useful feature.

[alogoc]

This feature would have been very useful in several operating scenarios, such as setting proxy settings before a deployment.

[adamish]

Can anyone comment on what alternatives are? Without this feature we'll have a lot of duplication. No one likes duplication.

We can address the Environment variables via ConfigMap and the envFrom keyword, however I cannot see anything for volumes, imagePullSecret etc.

[justinfx]

It seems the alternative is just to use mutating webhooks. And there is even a port of PodPreset to a mutating web hook by redhat:
https://github.com/redhat-cop/podpreset-webhook

[mingfang]

-1000
Removing PodPreset is terrible. Shame on you!

[devlounge]

It seems the alternative is just to use mutating webhooks. And there is even a port of PodPreset to a mutating web hook by redhat:
https://github.com/redhat-cop/podpreset-webhook

It doesn't look much maintained and active, sadly

[jglick]

Related: #48180