KEP-2299: Update KEP for move to implementable #2910
Conversation
k8s-ci-robot
added
cncf-cla: yes
|
/assign @ehashman |
| # generate resources for a Java application | ||
| - apiVersion: example.com/v1 | ||
| kind: JavaApplication | ||
| provider: {container: {image: example/module_providers/java:v1.0.0}} | ||
| provider: {container: {image: docker.example.co/kustomize_transformers/java:v1.0.0}} |
There was a problem hiding this comment.
Apologies if this is addressed elsewhere (I could not find it), but is this provider configuration intended to be identical to the provider configuration proposed by catalog?
There was a problem hiding this comment.
This is just https://github.com/kubernetes-sigs/kustomize/blob/master/kyaml/fn/runtime/runtimeutil/functiontypes.go#L128, which currently surfaces as an annotation containing JSON data. This KEP is proposing that that information be moved from the annotation to this reserved field, at least within Composition. It is not proposing any particular changes to the data within.
Edit: Catalog might need to propose some changes (particularly to improve exec functionality), but generally speaking I think this should be the same structure everywhere it ultimately surfaces.
| specific allowlists compiled in, and for additional sources to be allowlisted at | ||
| invocation time. | ||
| This proposal effectively takes a feature set that exists in Kustomize today and makes it much more | ||
| usable in certain workflows. As such, it does not come with any novel technical risks. |
There was a problem hiding this comment.
I noticed you removed the section stating that container-based functions will be run without networking or volume access. Does that mean Composition will support the network and mounts fields?
This question is coming in part from wanting clarity about the syntax proposed in https://github.com/kubernetes/enhancements/pull/2908/files#r699656279, which seems to suggest changing the container spec; I'm wondering if Composition is assuming the same changed UX.
EDIT: Thinking about it more and I guess this is out of scope for this KEP. So long as Catalog and Composition are using the same UX this is not an issue and can be discussed on the catalog KEP instead.
There was a problem hiding this comment.
Correct, this KEP itself doesn't change the fields required/supported for any particular plugin type. It will support whatever options are present when it merges.
k8s-ci-robot
added
the
lgtm
|
This is not currently being tracked by RT, can you add to https://docs.google.com/spreadsheets/d/1P1J1QpayRmh2SNjs8T-wBCb6SgEOdWTRQ7MBol7yibk/edit#gid=1954476102 |
|
@ehashman I don't think it belongs in that spreadsheet. It's a Kustomize-internal feature, and Kustomize has an independent release cycle. As I said in the PR description, this KEP exists in k/enhancements because we didn't have a Kustomize-internal process until extremely recently, and I'm open to moving this KEP to the Kustomize repo if that is preferred. |
This enhancement is really out of tree, it's purely an implementation of something within Kustomize (and won't land in kubectl), so I don't think this needs to be tracked in the release spreadsheet. I think we'd track it if there was something interesting to drop in the release notes, but I don't think we need to...I also don't think it needs a PRR? Probably gets back to the proposed |
I assume design docs in k/enhancements generally require wider discussion outside the sponsoring SIG and if that's not the case this probably isn't the right place. |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ehashman, KnVerey, monopole, soltysh The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
module->transformer). Content that actually belonged in the Catalog KEP instead of here has been removed. This KEP's implications no longer extend beyond the introduction of a new Kind that is processed differently during Kustomize builds.Please note that this is a Kustomize-internal feature that does not introduce any novel risks. I think it would have been a good candidate for the in-repo mini proposal process discussed with the SIG and proposed in kubernetes-sigs/kustomize#4128, had that existed at the time of initial drafting. I'm open to moving it there now rather than promoting to implementable, if that is what reviewers desire. IMO the most compelling reason for it to remain on k/enhancements is that a couple other in-flight KEPs that do have broader implications mention it.
/cc @jeremyrickard @monopole @natasha41575