diff --git a/keps/sig-cli/3104-introduce-kuberc/README.md b/keps/sig-cli/3104-introduce-kuberc/README.md index 072739a0d6a..1b178472077 100644 --- a/keps/sig-cli/3104-introduce-kuberc/README.md +++ b/keps/sig-cli/3104-introduce-kuberc/README.md @@ -139,13 +139,13 @@ Items marked with (R) are required *prior to targeting to a milestone / release* - [x] (R) Design details are appropriately documented - [ ] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input (including test refactors) - [ ] e2e Tests for all Beta API Operations (endpoints) - - [ ] (R) Ensure GA e2e tests for meet requirements for [Conformance Tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/conformance-tests.md) + - [ ] (R) Ensure GA e2e tests for meet requirements for [Conformance Tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/conformance-tests.md) - [ ] (R) Minimum Two Week Window for GA e2e tests to prove flake free - [ ] (R) Graduation criteria is in place - - [ ] (R) [all GA Endpoints](https://github.com/kubernetes/community/pull/1806) must be hit by [Conformance Tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/conformance-tests.md) -- [ ] (R) Production readiness review completed -- [ ] (R) Production readiness review approved -- [ ] "Implementation History" section is up-to-date for milestone + - [ ] (R) [all GA Endpoints](https://github.com/kubernetes/community/pull/1806) must be hit by [Conformance Tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/conformance-tests.md) +- [x] (R) Production readiness review completed +- [x] (R) Production readiness review approved +- [x] "Implementation History" section is up-to-date for milestone - [ ] User-facing documentation has been created in [kubernetes/website], for publication to [kubernetes.io] - [ ] Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes @@ -179,7 +179,7 @@ updates. [documentation style guide]: https://github.com/kubernetes/community/blob/master/contributors/guide/style-guide.md --> -This proposal introduces an optional `kuberc` file that is used to separate cluster credentials and server configuration from user preferences. +This proposal introduces an optional `kuberc` file that is used to separate cluster credentials and server configuration from user preferences. ## Motivation @@ -191,9 +191,11 @@ demonstrate the interest in a KEP within the wider Kubernetes community. [experience reports]: https://github.com/golang/go/wiki/ExperienceReports --> -kubectl is one of the oldest parts of the Kubernetes project and has a strong guarantee on backwards compatibility. We want users to be able to opt in to new behaviors (like delete confirmation) that may be considered breaking changes for existing CI jobs and scripts. +kubectl is one of the oldest parts of the Kubernetes project and has a strong guarantee on backwards compatibility. We want users to be able to opt in to new behaviors (like delete confirmation) that may be considered breaking changes for existing CI jobs and scripts. -[kubeconfigs already have a field for preferences](https://github.com/kubernetes/kubernetes/blob/474fd40e38bc4e7f968f7f6dbb741b7783b0740b/staging/src/k8s.io/client-go/tools/clientcmd/api/types.go#L43) that is currently underutilized. The reason for not using this existing field is that creating a new cluster generally yields a new kubeconfig file which contains credentials and host information. While kubeconfigs can be merged and specified by path, we feel there should be a clear separation between server configuration and user preferences. +[kubeconfig already has a field for preferences](https://github.com/kubernetes/kubernetes/blob/474fd40e38bc4e7f968f7f6dbb741b7783b0740b/staging/src/k8s.io/client-go/tools/clientcmd/api/types.go#L43) that is currently underutilized. The reason for not using this existing field is that creating a new cluster generally yields a new kubeconfig file which contains credentials and host information. While kubeconfigs can be merged and specified by path, we feel there should be a clear separation between server configuration and user preferences. + +Additionally, users can split kubeconfig files into various locations, while maintaining a single preference file that will apply no matter which `--kubeconfig` flag or `$KUBECONFIG` env var is pointing to. ### Goals @@ -303,7 +305,7 @@ required) or even code snippets. If there's any ambiguity about HOW your proposal will be implemented, this is the place to discuss them. --> -During alpha this feature will be enabled through the `ENABLE_KUBERC=true` environment variable. The file will default to being located in `~/.kube/kuberc`. A flag will allow overriding this default location with a path i.e. `kubectl --kuberc /var/kube/rc`. +During alpha this feature will be enabled through the `KUBECTL_KUBERC=true` environment variable. The file will default to being located in `~/.kube/kuberc`. A flag will allow overriding this default location with a path i.e. `kubectl --kuberc /var/kube/rc`. Three initial top level keys are proposed. @@ -324,8 +326,13 @@ kind: Preferences command: aliases: - alias: getdbprod - command: get pods -l what=database --namespace us-2-production - + command: get pods + flags: + - name: labels + default: what=database + - name: namespace + default: us-2-production + overrides: - command: apply flags: @@ -333,7 +340,7 @@ command: default: "true" - command: delete flags: - - name: confirm + - name: interactive default: "true" - command: "*" flags: @@ -387,10 +394,16 @@ https://testgrid.k8s.io/sig-testing-canaries#ci-kubernetes-coverage-unit This can inform certain test coverage improvements that we want to do before extending the production code to implement this enhancement. ---> - ``: `` - `` +--> + +We're planning unit tests covering: +- basic functionality +- config API fuzzy tests +- input validation and correctness + ##### Integration tests - : +--> + +We're planning at least the following integration tests: +- `KUBECTL_KUBERC` enablement and disablement +- basic functionality + ##### e2e tests - [ ] Events - - Event Reason: + - Event Reason: - [ ] API .status - - Condition name: - - Other field: + - Condition name: + - Other field: - [x] Other (treat as last resort) - Details: The command will be logged with kubectl -v 2 @@ -739,7 +757,7 @@ Pick one more of these and delete the rest. - Components exposing the metric: - [ ] Other (treat as last resort) - Details: - - + - Not applicable. ###### Are there any missing metrics that would be useful to have to improve observability of this feature? @@ -862,6 +880,20 @@ This through this both in small and large cases, again with respect to the No. +###### Can enabling / using this feature result in resource exhaustion of some node resources (PIDs, sockets, inodes, etc.)? + + + +No. + ### Troubleshooting