kubectl config drops all comments from kubeconfig file

[rm3l]

What happened:
I was documenting a relatively big Kubeconfig file, and just noticed that all the comments I had written disappeared after executing a kubectl config command to set the namespace of a given context.

What you expected to happen:
Not sure if that is the intended behavior (I couldn't find any existing issues related to that, nor any documentation about this), but I would expect my "carefully-crafted" comments to still be there after writing the namespace information with kubectl config ....

I've provided minimal reproduction steps below. Am I missing something?

How to reproduce it (as minimally and precisely as possible):

• Let's say you are adding a few comments to an existing kubeconfig:

❯ mkdir -p /tmp/test-kube-config/config && cd /tmp/test-kube-config/config

❯ cat <<EOF > /tmp/test-kube-config/config
apiVersion: v1

clusters:
# My development cluster
- cluster:
    certificate-authority: fake-ca-file
    server: https://1.2.3.4
  name: development
# My experimental cluster. We don't care about TLS validation
- cluster:
    insecure-skip-tls-verify: true
    server: https://5.6.7.8
  name: scratch

contexts:
- context:
    cluster: development
    user: developer
  name: dev-frontend
- context:
    cluster: development
    user: developer
  name: dev-storage
- context:
    cluster: scratch
    user: experimenter
  name: exp-scratch
current-context: scratch

kind: Config
preferences: {}

users:
- name: developer
  user:
    client-certificate: fake-cert-file
    client-key: fake-key-seefile
- name: experimenter
  user:
    password: some-password
    username: exp
EOF

• Versioning the file to be able to see the diff

❯ git init && git add -A . && git commit -m "add kubeconfig with comments"

• Now set the namespace for the dev-frontend context, using kubectl config:

❯ kubectl config --kubeconfig=/tmp/test-kube-config/config set-context dev-frontend --namespace dev-fe

• Context namespace has been correctly set, but all comments have been removed

❯ git diff

diff --git a/config b/config
index 28a4446..fe9b393 100644
--- a/config
+++ b/config
@@ -1,20 +1,17 @@
 apiVersion: v1
-
 clusters:
-# My development cluster
 - cluster:
     certificate-authority: fake-ca-file
     server: https://1.2.3.4
   name: development
-# My experimental cluster. We don't care about TLS validation
 - cluster:
     insecure-skip-tls-verify: true
     server: https://5.6.7.8
   name: scratch
-
 contexts:
 - context:
     cluster: development
+    namespace: dev-fe
     user: developer
   name: dev-frontend
 - context:
@@ -26,10 +23,8 @@ contexts:
     user: experimenter
   name: exp-scratch
 current-context: scratch
-
 kind: Config
 preferences: {}
-
 users:
 - name: developer
   user:

Anything else we need to know?:
I guess this has something to do with the way this YAML document is marshaled/unmarshaled.

Environment:

• Kubernetes client and server versions (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.3", GitCommit:"aef86a93758dc3cb2c658dd9657ab4ad4afc21cb", GitTreeState:"clean", BuildDate:"2022-07-13T14:30:46Z", GoVersion:"go1.18.3", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v4.5.4
Server Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.2", GitCommit:"f66044f4361b9f1f96f0053dd46cb7dce5e990a8", GitTreeState:"clean", BuildDate:"2022-06-23T22:20:14Z", GoVersion:"go1.18.3", Compiler:"gc", Platform:"linux/amd64"}

• Cloud provider or hardware configuration: KinD local cluster
• OS (e.g: cat /etc/os-release): Fedora release 36 (Thirty Six)

[k8s-ci-robot]

@rm3l: This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[brianpursley]

I don't think it is intended behavior, just unfortunate behavior. This happens because it deserializes the yaml, makes the changes, and then serializes it back out.

Comments are lost during deserialization.

I don't know offhand if there is some way to possibly preserve them, maybe do some kind of patch/merge of the yaml instead of completely overwriting it?

[eddiezane]

This may potentially be addressed if we move to a go-yaml v3 which supports comments. Though some work would definitely need to be done to preserve them when serializing with kubectl config.

ref kubernetes-sigs/yaml#72

I understand it's annoying to have your comments dropped but right now I would say this is a "won't fix" for us.

[rm3l]

I understand. Thanks, @brianpursley, and @eddiezane for your feedback.

[ardaguclu]

As discussed this is an unfortunate behavior which can not be fixed easily. I'm closing this and feel free re-open it if you think otherwise.

/close

[k8s-ci-robot]

@ardaguclu: Closing this issue.

In response to this:

As discussed this is an unfortunate behavior which can not be fixed easily. I'm closing this and feel free re-open it if you think otherwise.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.