[question] --enable_alpha_plugins

[lelandsindttouchnet]

Is there a roadmap/plan to promote plugin support from alpha to beta -or- supported?

[lelandsindttouchnet]

previously asked: #1609

[lelandsindttouchnet]

also relevant: #1504

[lelandsindttouchnet]

Trying to add some commentary to this query...

I am getting some internal pushback as I advocate for the use of Kustomize in production, specifically when used in combination with plugins requiring the --enable_alpha_plugins option.

I could reference @monopole in #1504 The purpose of this flag was to warn the user against accidentally running 3rd party plugins. but that is at least partly contradicted by the documentation. The use of this flag is an opt-in acknowledging the unstable (alpha) plugin API, the absence of plugin provenance, and the fact that a plugin is not part of kustomize.

Should I expect to see continued support for 3rd party plugins from Kustomize, understanding the responsibility for reviewing and trusting said 3rd party plugins?

[lelandsindttouchnet]

Searched for kustomize plugin, limit to Repositories, order by stars...

Forgive me if you dislike being @-ed. I was hoping that as the maintainers/main contributors of the most popular (by stars) kustomize plugins you might have some input here.

@devstein @jcassee @donbowman @amarrella

[lelandsindttouchnet]

Another interesting data point...
https://github.com/search?l=Markdown&q=--enable_alpha_plugins&type=Code

82 markdown documents with references to --enable_alpha_plugins across github.

[amarrella]

I wouldn't call my plugin popular, but as a user i'd love to see this supported in stable (and possibly in kubectl with apply-k)

[donbowman]

my conclusion was:
a) we need plugins otherwise workflow is very complex and duplicative
b) the compiled in go so are not stable
c) the exec plugins work well, have been using for >1 yr

so my vote is, remove the flag, let them fly. You can't accidentally run a random plugin, they have to be in a well defined location that is not likely to be on unix path.

[devstein]

Agree with @donbowman plugins allow the last-mile flexibility that is very useful for helping simplifying user/company-specific workflows.

Go plugins are finicky but do the job. I think there is work to be done to unify the functionality and interface between the Go and Exec plugins. For example, one issue I've made is around the inconsistency and lack of support for behavior annotations for Go plugin.

I can't claim security expertise, but because the plugin has to be installed to a specific path it definitely reduces the possibility of pure accidental execution of third party plugins. I also love the idea of code and security reviewed "kustomize certified/approved" plugins.

Another point of reference is Google's kpt functions offer very similar functionality to Kustomzie plugins.

Overall, I'm in favor of promoting it.

[lelandsindttouchnet]

Thank you all for the additional conversation and insights.

For what it's worth I would be happy with/fully understand the need for a flag that makes clear some risk. It's the alpha that makes it hard to promote kustomize plugins into production deployments.

It implies that the feature could radically change or be suddenly removed.

[HumairAK]

Has there been any update on this? Would be great if the flag was just --enable-plugins or something similar, provided that the reason is indeed only to "warn the user against accidentally running 3rd party plugins".

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[lelandsindttouchnet]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[HumairAK]

/remove-lifecycle stale

[KnVerey]

I strongly agree about the importance of plugins and would like to promote them, but some issues will need to be resolved as part of that. I have written up a KEP with a plan: kubernetes/enhancements#2954. If you are interested in this topic, I would love to get your feedback--please comment on that PR rather than here and follow the KEP issue going forward.

Here is the full series of KEPs we are working on to making Kustomize plugins better:

• Kustomize Plugin Graduation kubernetes/enhancements#2953 (proposal in PR)
• Kustomize KRM Plugin Catalog kubernetes/enhancements#2906 (proposal in PR)
• Kustomize Plugin Composition API kubernetes/enhancements#2299 (implementable)
• Public KRM functions registry kubernetes/enhancements#2985 (proposal in PR)

[LelandSindt]

@KnVerey forgive the "at" --- is it safe to assess that the above listed enhancements stalled out? -- do you have any insight into the likelihood of "graduating" plugins out of alpha?