New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Epic: Kpt OpenAPI roadmap #1521
Comments
@mengqiy umbrella issue for the openapi work |
we may also want to look into kubernetes-sigs/kustomize#3670 |
I'd consider moving this into "In Progress" if it's actively being worked on. |
Could we link some questions or issues that were filed because this feature didn't exist? It would be great to get back to those users and see if we are addressing their needs and also could be early design partners. |
I will link issues if they arise. The main goal here is to make sure the UX for functions is good, so we are welcoming any input from users on that. |
I have rarely seen a feature well received if it wasn't addressing a problem that customers already knew they had. |
This is a cross-cutting and critical part of having good UX when manipulating KRM resources. Even most basic functions like name-prefix require augmented OpenAPI semantics to work properly. Kustomize has done this for core k8s native types based on a real need, we need to generalize and extend this. |
Another note: because kustomize had only been built with OpenAPI for native types, issues have come up regarding the lack of OpenAPI support for CRDs (see kubernetes-sigs/kustomize#2825, kubernetes-sigs/kustomize#1689, kubernetes-sigs/kustomize#3677). It will be good if kpt can learn from this and support it early on. |
This is an umbrella issue describing the tasks that @mengqiy outlined, for OpenAPI features in kpt
Why do we need to do this?
We want our tools to work well with custom resources. We want our functions to have a good UX and custom resources work like builtin types, so that users don't have to provide their own hardcoded fieldspecs for their CRDs (see this example). Instead of having to provide their own fieldspecs, we would like to see if they can be inferred from OpenAPI instead, and make CRDs work like builtins. For this to work, we need to build OpenAPI extensions so that the necessary metadata is available for kpt and kpt functions.
We also want users to have a good UX including a separation between CRD authors and function consumers. In an ideal workflow, the CRD author would provide the OpenAPI specification and extensions needed to use their CRD, and function users would be able to use them seamlessly. These users would only need to provide their desired fields without including the fieldspec metadata that can be provided by the author.
Not only does this affect functions, but kpt uses OpenAPI data for merging packages. 3-way merge requires metadata from OpenAPI (to get merge key and patch strategy information). 3-way merge is necessary for kpt package update. If a user can provide their own OpenAPI doc, then they can also control how kpt merges resources.
Why do this now?
Because this work may take a few months, and ideally this would be available for kpt functions in the function catalog when they are ready. It is better to start now rather than start when the need arises. This will impact every function that needs metadata from OpenAPI which will affect most functions in the function catalog.
The text was updated successfully, but these errors were encountered: