Update kustomize version that's shipped in kubectl? #1500
Assignees
Labels
lifecycle/frozen
Indicates that an issue or PR should not be auto-closed due to staleness.
priority/important-soon
Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
triage/accepted
Indicates an issue or PR is ready to be actively worked on.
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. |
k8s-ci-robot
added
the
lifecycle/stale
|
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. |
k8s-ci-robot
added
lifecycle/rotten
|
/remove-lifecycle rotten |
k8s-ci-robot
removed
the
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. |
k8s-ci-robot
added
the
lifecycle/stale
|
Any update on this? |
|
/remove-lifecycle stale |
k8s-ci-robot
removed
the
lifecycle/stale
This was referenced Jun 30, 2020
This was referenced Aug 20, 2020
Merged
This was referenced Sep 16, 2020
|
Another umbrella issue about removing apimachinery and related libraries. #2506 |
2 tasks
|
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. |
monopole
added a commit
to monopole/kustomize
that referenced
this issue
Feb 4, 2021
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 ```
monopole
added a commit
to monopole/kustomize
that referenced
this issue
Feb 4, 2021
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/... ```
monopole
added a commit
to monopole/kustomize
that referenced
this issue
Feb 4, 2021
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/... ```
monopole
added a commit
to monopole/kustomize
that referenced
this issue
Feb 4, 2021
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/... ```
This was referenced Feb 4, 2021
2 tasks
10 tasks
This was referenced Mar 3, 2021
Closed
solsson
added a commit
to Yolean/ystack
that referenced
this issue
Jun 27, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: