-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Update kustomize version that's shipped in kubectl? #1500
Comments
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
It was mentioned in #1267 (comment) that the intention is for each Is this issue the correct place to be tracking progress on this? Just for context: the mismatch in functionality is a proving bit inconvenient for us when we're trying to build automation around See also: #1424 |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle rotten |
Not sure if I'm supposed to marking this issue as fresh. My apologies if not. From my perspective I think this is still an issue and some guidance would be appreciated as we're attempting to use kustomize in automation. Sounds like from the discussion in kubernetes/kubernetes#85146 that there might be a different approach proposed here? |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Any update on this? |
/remove-lifecycle stale |
Another umbrella issue about removing apimachinery and related libraries. #2506 |
Update: targetting kubectl release v1.21, code freeze. Per: https://www.kubernetes.dev/resources/release/
The best way to help on this issue is use and report bugs in the latest standalone version of kustomize in the 3.9 series - e.g. v3.9.2. This instance of the kustomize CLI uses the same kustomize libraries which will be linked into kubectl via normal import mechanisms; we're shaking some final bugs. Kustomize releases every two weeks, while kubectl releases at most once a qtr. |
The PR seeks to expose some of the top level kustomize commands (especially `build`) for reuse in other command line tools (expecially `kubectl`, see kubernetes-sigs#1500). ``` REPO/api/go.mod REPO/api/builtins REPO/api/kommands <- new REPO/api/... ``` This would make `api` module depend on cobra. That's bad for people who want to depend on the api, but want to write their own commands at their own version of cobra. The commands module and the api module should remain distinct. Put them in a new module along side `api`, e.g. ` ``` REPO/api/go.mod REPO/api/builtins REPO/api/... REPO/kommands/go.mod REPO/kommands/build REPO/kommands/edit REPO/kommands/... ``` This has the problem (or advantage) that the commands and the kustomize binary now evolve separately with their own version numbers. Just move them up out of internal. ``` REPO/api/go.mod REPO/api/builtins REPO/api/... REPO/kustomize/go.mod REPO/kustomize/main.go REPO/kustomize/kommands/build REPO/kustomize/kommands/edit REPO/kustomize/kommands/... ``` Outside users, e.g. kubectl, could then ``` import sigs.k8s.io/kustomize/kustomize/v3/kommands/build ``` and hopefully still get the `main` package as they do now via: ``` go get sigs.k8s.io/kustomize/kustomize/v3 ```
The PR seeks to expose some of the top level kustomize commands (especially `build`) for reuse in other command line tools (expecially `kubectl`, see kubernetes-sigs#1500). Options 1. Expose the commands in the `api` module. ``` REPO/api/go.mod REPO/api/builtins REPO/api/kommands <- new REPO/api/... ``` Disadvantage: This would make `api` module depend on cobra. That's bad for people who want to depend on the api, but want to write their own commands at their own version of cobra. The commands module and the api module should remain distinct. 2. Expose the commands in their own `commands` module. They'd appear alongside `api`, e.g. ` ``` REPO/api/go.mod REPO/api/builtins REPO/api/... REPO/commands/go.mod REPO/commands/build REPO/commands/edit REPO/commands/... ``` Advantage: The commands would be consumed by the kustomize binary and the kubectl binary in the same way. Disadvantage: THe kustomize binary module and the commands module would evolve separately with their own version numbers, creating confusion. 3. Expose the commands in the existing `kustomize` module ``` REPO/api/go.mod REPO/api/builtins REPO/api/... REPO/kustomize/go.mod REPO/kustomize/main.go REPO/kustomize/kommands/build REPO/kustomize/kommands/edit REPO/kustomize/kommands/... ``` Outside users, e.g. kubectl, could then ``` import sigs.k8s.io/kustomize/kustomize/v3/kommands/build ``` and hopefully still get the `main` package as they do now via: ``` go get sigs.k8s.io/kustomize/kustomize/v3 ``` Advantage: 1) The commands and the kustomize binary sit at the same version, so it's easy to see which version of kustomize is being used by some other CLI. 2) The path to the binary doesn't change. Disadvantage: It appears to be non-standard to place a main package at the top level of a module that also ships subpackages. Usually `main` packages live as leaves under a directory called `cmd`. This might cause some problems. If so, we can go with option 4. 4. Same as 3, but move `main.go` down one step. ``` REPO/api/go.mod REPO/api/builtins REPO/api/... REPO/kustomize/go.mod REPO/kustomize/cmd/main.go REPO/kustomize/kommands/build REPO/kustomize/kommands/edit REPO/kustomize/kommands/... ```
The PR seeks to expose some of the top level kustomize commands (especially `build`) for reuse in other command line tools (expecially `kubectl`, see kubernetes-sigs#1500). Options 1. Expose the commands in the `api` module. ``` REPO/api/go.mod REPO/api/builtins REPO/api/kommands <- new REPO/api/... ``` Disadvantage: This would make `api` module depend on cobra. That's bad for people who want to depend on the api, but want to write their own commands at their own version of cobra. The commands module and the api module should remain distinct. 2. Expose the commands in their own `commands` module. They'd appear alongside `api`, e.g. ` ``` REPO/api/go.mod REPO/api/builtins REPO/api/... REPO/commands/go.mod REPO/commands/build REPO/commands/edit REPO/commands/... ``` Advantage: The commands would be consumed by the kustomize binary and the kubectl binary in the same way. Disadvantage: The kustomize binary module and the commands module would evolve separately with their own version numbers, creating confusion. 3. Expose the commands in the existing `kustomize` module ``` REPO/api/go.mod REPO/api/builtins REPO/api/... REPO/kustomize/go.mod REPO/kustomize/main.go REPO/kustomize/commands/build REPO/kustomize/commands/edit REPO/kustomize/commands/... ``` Outside users, e.g. kubectl, could then ``` import sigs.k8s.io/kustomize/kustomize/v3/commands/build ``` and hopefully still get the `main` package as they do now via: ``` go get sigs.k8s.io/kustomize/kustomize/v3 ``` Advantage: 1) The commands and the kustomize binary sit at the same version, so it's easy to see which version of kustomize is being used by some other CLI. 2) The path to the binary doesn't change. Disadvantage: It appears to be non-standard to place a main package at the top level of a module that also ships subpackages. Usually `main` packages live as leaves under a directory called `cmd`. This might cause some problems. If so, we can go with option 4. 4. Same as 3, but move `main.go` down one step. ``` REPO/api/go.mod REPO/api/builtins REPO/api/... REPO/kustomize/go.mod REPO/kustomize/cmd/main.go REPO/kustomize/commands/build REPO/kustomize/commands/edit REPO/kustomize/commands/... ```
The PR exposes some of the top level kustomize commands (especially `build`) for reuse in other command line tools (expecially `kubectl`, see kubernetes-sigs#1500). This PR represents option 3 from the following list of ways this exposure could be arranged. 1. Expose the commands in the `api` module. ``` REPO/api/go.mod REPO/api/builtins REPO/api/commands <- new REPO/api/... ``` Disadvantage: This would make `api` module depend on cobra. That's bad for clients that want to depend on the api, but want to write their own commands at their own version of cobra. The `api` module shouldn't depend on UX libraries like cobra. 2. Expose the commands in their own `commands` module. They'd appear alongside `api`, e.g. ` ``` REPO/api/go.mod REPO/api/builtins REPO/api/... REPO/commands/go.mod REPO/commands/build REPO/commands/edit REPO/commands/... ``` Advantage: The commands would be consumed by the kustomize binary and the kubectl binary in the same way. Disadvantage: The kustomize binary module and the commands module could evolve separately with their own version numbers, creating confusion. 3. Expose the commands in the existing `kustomize` module ``` REPO/api/go.mod REPO/api/builtins REPO/api/... REPO/kustomize/go.mod REPO/kustomize/main.go REPO/kustomize/commands/build REPO/kustomize/commands/edit REPO/kustomize/commands/... ``` Outside users, e.g. kubectl, could then ``` import sigs.k8s.io/kustomize/kustomize/v3/commands/build ``` and hopefully still get the `main` package as they do now via: ``` go get sigs.k8s.io/kustomize/kustomize/v3 ``` Advantage: 1) The kustomize binary ships at the same version as the commands - which makes sense as the binary's _version_ refers to how the CLI operates (command names, flags, etc.). This makes it easy to related the version of a kustomize binary with the version of commands running in some other CLI binary. 2) The path to the kustomize binary doesn't change. Disadvantage: It's an atypical Go module arrangement. Usually `main` packages live as leaves under a directory called `cmd` inside a module, rather than at the _top_ of the module. This might cause some problems. If so, we can go with option 4. 4. Same as 3, but move `main.go` (the `main` package) down one step. ``` REPO/api/go.mod REPO/api/builtins REPO/api/... REPO/kustomize/go.mod REPO/kustomize/cmd/main.go REPO/kustomize/commands/build REPO/kustomize/commands/edit REPO/kustomize/commands/... ```
Not sure where the right repository is for this, maybe here, maybe https://github.com/kubernetes/kubectl, maybe https://github.com/kubernetes/kubernetes?
Kubernetes has just released v1.16.0-beta.2 and so far I haven't seen anything about a new kustomize version in the changelogs. I think if we want to have an updated version shipped in kubectl 1.16, we need to do something in the near future.
Are there any plans for updating the kustomize version that's integrated into kubectl?
The text was updated successfully, but these errors were encountered: