k9s/config.yaml configuration file is overwritten on launch

[KevinGimbel]

Describe the bug
k9s overwrites changes to the config file in $XGD_HOME/k9s/config.yaml.

To Reproduce

1. Make changes in X
2. Open k9s
3. File has been reset to the "default"

Expected behavior
My customisations are not removed, or a different file is provided for customisations.
add screenshots to help explain your problem.

Versions (please complete the following information):

• OS: MacOS 14.0
• K9s: v0.30.7
• K8s: Any

Additional context

I wanted to use a light skin for all clusters, previously this was easily done now I need to create a config file for each individual cluster, which is not viable when managing a lot of clusters.

Mildly related to #2324

[qlimenoque]

I have the same problem. I want to keep a common configuration for all clusters in config.yaml (i.e. the same skin) and extend it per cluster if needed.

[derailed]

@KevinGimbel Thank you for reporting this Kevin!
Could you be more specific and share exactly what you've changed in the base config.yaml file and what was reset to default?

[fxbtr]

You can still have a skin for all clusters by adding a key k9s.ui.skin: your_light_skin in the parent config.yaml
With a corresponding skin your_light_skin.yaml in skins/

[KevinGimbel]

You can still have a skin for all clusters by adding a key k9s.ui.skin: your_light_skin

@fxbtr which config.yaml do you mean?

@derailed I just realised I made a mistake: I added a config to k9s.skin instead of k9s.ui.skin - the latter works as expected!

I didn't see any issues in the logs tho, it could be helpful to log wrong configurations or unexpected values.

[calmacroi]

as a workaround for now (on OSx) following adjustment helped me keeping my favorites:
edit file: /Users/USERNAME/Library/Application Support/k9s/clusters/CLUSTERNAME/CONTEXT-NAME/config.yaml

this file apparently is taken as the default for overriding the XDG config file. also put the readOnly: true and lockFavorites: true in the above mentioned file

[mamorett]

Hi all. I noticed the same behavior on Ubuntu. I edit the .config/k9s/config.yaml file and when I start up k9s these changes got ignored. When I close k9s and open again the config file all my changes are not there and the file reverted to defaults.

[BrunoKrugel]

Same behavior on mac OS, it started happening in v0.30.8
the config.yaml is overriden to the default after opening k9s

[derailed]

@KevinGimbel @calmacroi @BrunoKrugel Thank you for reporting this!
Can you guys be very specific about which config files are involved and what were the exact changes you've made that got reverted?
Thank you for the gory details here!

[calmacroi]

@derailed i only tried to keep my favorite namespaces, also by adding the reduced config file in the clusters subpath of the XDG_CONFIG as the new config way for cluster specfic config (./cluster/clustername/context-name/config.yaml)
but even there the favorites got replaced by the initial configuration respectively after changing namespaces the choosen namespaces got saved. i found them in the /Users/USERNAME/Library/Application Support/k9s/clusters/CLUSTERNAME/CONTEXT-NAME/config.yaml file so i changed that in order to keep my fav-namespaces...

[KevinGimbel]

@derailed I did the following

1. Add k9s.skin to $XGD_HOME/k9s/config.yaml
2. Open k9s, no skin applied
3. Open $XGD_HOME/k9s/config.yaml again, the k9s.skin key is removed

[KevinGimbel]

@derailed could it be that k9s checks if the config file is a "new one" and if it doesn't match replaces it with the default? Because by setting the wrong key k9s.skin the file could be recognised as invalid or old maybe?

[derailed]

Very kind! Thank you all for adding details here!!
I think the issue here is K9s validates the config and updates to disk.
Going to intro schema validation on the next drop and just have k9s boark if the configs dont validate on load vs trying to fix and potentially wipe out users updates.
There are 2 scenarios here ie the application global skin in the root config which should read k9s.ui.skin: xxx and the context specific skin in the cluster/context/config.yaml which should read k9s.skin: xxx.
Does this make sense?

Hoping the next drop will fix these issues... Crossing fingers AND toes!!