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!!

[KevinGimbel]

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?

Why are the keys different? I would expect both to be the same, so either k9s.skin or k9s.ui.skin. Looking into the future (🔮) I think using k9s.ui.skin makes more sense so that other UI configurations can live in the same scope.

[OddKMS]

I would like to add that the bug also strips any comments from the config file.
I'd love to keep them as I have an extensively commented version of the config in order to ease introduction to new teammembers at work.

[derailed]

Please give v0.31.0 a rinse and see if we're happier. Tx!

[KevinGimbel]

With v0.31.1 i get a go error:

Error: k9s config file "/Users/kevin/.config/k9s/config.yaml" load failed:
Additional property fullScreenLogs is not allowed

panic: k9s config file "/Users/kevin/.config/k9s/config.yaml" load failed:
Additional property fullScreenLogs is not allowed

goroutine 1 [running]:
github.com/derailed/k9s/cmd.Execute(...)
        github.com/derailed/k9s/cmd/root.go:60
main.main()
        github.com/derailed/k9s/main.go:32 +0x4c

Full log

Error: k9s config file "/Users/kevin/.config/k9s/config.yaml" load failed:
Additional property fullScreenLogs is not allowed
Usage:
  k9s [flags]
  k9s [command]
Available Commands:

completion  Generate the autocompletion script for the specified shell

help        Help about any command

info        List K9s configurations info

version     Print version/build info
Flags:

-A, --all-namespaces                 Launch K9s in all namespaces

--as string                      Username to impersonate for the operation

--as-group stringArray           Group to impersonate for the operation

--certificate-authority string   Path to a cert file for the certificate authority

--client-certificate string      Path to a client certificate file for TLS

--client-key string              Path to a client key file for TLS

--cluster string                 The name of the kubeconfig cluster to use

-c, --command string                 Overrides the default resource to load when the application launches

--context string                 The name of the kubeconfig context to use

--crumbsless                     Turn K9s crumbs off

--headless                       Turn K9s header off

-h, --help                           help for k9s

--insecure-skip-tls-verify       If true, the server's caCertFile will not be checked for validity

--kubeconfig string              Path to the kubeconfig file to use for CLI requests

--logFile string                 Specify the log file (default "/Users/kevin/Library/Application Support/k9s/k9s.log")

-l, --logLevel string                Specify a log level (info, warn, debug, trace, error) (default "info")

--logoless                       Turn K9s logo off

-n, --namespace string               If present, the namespace scope for this CLI request

--readonly                       Sets readOnly mode by overriding readOnly configuration setting

-r, --refresh int                    Specify the default refresh rate as an integer (sec) (default 2)

--request-timeout string         The length of time to wait before giving up on a single server request

--screen-dump-dir string         Sets a path to a dir for a screen dumps

--token string                   Bearer token for authentication to the API server

--user string                    The name of the kubeconfig user to use

--write                          Sets write mode by overriding the readOnly configuration setting
Use "k9s [command] --help" for more information about a command.
panic: k9s config file "/Users/kevin/.config/k9s/config.yaml" load failed:

Additional property fullScreenLogs is not allowed
goroutine 1 [running]:

github.com/derailed/k9s/cmd.Execute(...)

github.com/derailed/k9s/cmd/root.go:60

main.main()

github.com/derailed/k9s/main.go:32 +0x4c

[KevinGimbel]

Already tracked in #2442

---

If I remove my config I can start k9s.

The issue seems to be that logger.fullScreenLogs was renamed to logger.fullScreen.

This is my config yaml:

config.yaml

k9s:
  liveViewAutoRefresh: false
  screenDumpDir: /Users/kevin/Library/Application Support/k9s/screen-dumps
  refreshRate: 2
  maxConnRetry: 5
  readOnly: false
  noExitOnCtrlC: false
  ui:
    enableMouse: false
    headless: false
    logoless: false
    crumbsless: false
    noIcons: false
    skin: current # name of the theme i want to use
  skipLatestRevCheck: false
  disablePodCounting: false
  shellPod:
    image: busybox:1.35.0
    namespace: default
    limits:
      cpu: 100m
      memory: 100Mi
  imageScans:
    enable: false
    exclusions:
      namespaces: []
      labels: {}
  logger:
    tail: 100
    buffer: 5000
    sinceSeconds: -1
    fullScreenLogs: false
    textWrap: false
    showTime: false
  thresholds:
    cpu:
      critical: 90
      warn: 70
    memory:
      critical: 90
      warn: 70

[calmacroi]

@derailed : so still the same behaviour for me. i sum up (valid for OSx):

having in my XDG_CONFIG dir:
./k9s/clusters/SC@MTF/SC@MTF/config.yaml

k9s:
  cluster: SC@MTF
  readOnly: false
  namespace:
    active: development
    lockFavorites: true
    favorites:
    - all
    - development
    - prelive
    - live
    view:
      active: dp
    featureGates:
      nodeShell: false
    portForwardAddress: localhost

in the Application Support dir:
./config.yaml
and no ./cluster/XXX..... directory

after starting k9s the first time in v0.31.1 a folder in the Application Support directory gets created containing:

k9s:
  cluster: SC@MTF
  namespace:
    active: default
    lockFavorites: false
    favorites:
    - default
  view:
    active: po
  featureGates:
    nodeShell: false
  portForwardAddress: localhost

and the favorites (and likely all other settings) are taken from this file instead of the created config.yaml in XDG_HOME/cluster/SC@MTF/SC@MTF/

editing the one in Application Support (setting namespace/active: development) is resetted whenever i start k9s to namepsace/active: default.

[alexaasha]

The same thing in Ubuntu 22. After installing of new version of k9s via webi, new config.yaml has been created.

[derailed]

@calmacroi Thanks for the details! Can you share the output of k9s info and attach your k9s debug logs? Tx!
Also please watch for XDG setup: https://youtu.be/X3444KfjguE

[1nval1d]

I observe a similar behaviour as @calmacroi described with version 0.31.2 on Mac OS 14.2.1.
k9s/config.yaml:

k9s: {}

starting up it loads. the defaults and goes into pods in default namespace.
Then it creates a cluster entry with config:

k9s:
  cluster: cluster_placeholder
  namespace:
    active: default
    lockFavorites: false
    favorites:
    - default
  view:
    active: po
  featureGates:
    nodeShell: false
  portForwardAddress: localhost

If I change in k9s to any other namespace, the active value in the cluster config gets updated to that value.
So far as expected.

But on starting k9s again, it goes back to default namespace and overrides the active config in the cluster/config.yaml to default. Changing the config manually results in the same behaviour.
If the namespace favorites are unlocked and default is removed manually from them, it will add default again. (I guess also expected as a result of the original bug?)

I first noticed this behaviour when switching from 0.30.8 to 0.31.0, I have tried it with 0.31.1 aswell and all 3 versions show the same behaviour.

Here is the debug log of the two startups, first without a cluster config and changing the namespace then closing k9s, starting it again and being back in default.

I changed the path to shorten the lines and keep my username private.

10:07PM INF 🐶 K9s starting up...
10:07PM DBG Context config not found! Generating... "~/Library/Application Support/k9s/cluster_placeholder/dev/config.yaml"
10:07PM DBG Active Context "dev"
10:07PM INF ✅ Kubernetes connectivity
10:07PM DBG No custom skin found. Using stock skin
10:07PM DBG Factory START with ns `"default"
10:07PM DBG Fetching latest k9s rev...
10:07PM DBG K9s latest rev: "v0.31.2"
10:07PM DBG No custom skin found. Using stock skin
10:07PM DBG TABLE-UPDATER canceled -- "v1/pods"
10:07PM INF 🐶 K9s starting up...
10:07PM DBG Found existing context config: "~/Application Support/k9s/clusters/cluster_placeholder/dev/config.yaml"
10:07PM DBG Active Context "dev"
10:07PM INF ✅ Kubernetes connectivity
10:07PM DBG No custom skin found. Using stock skin
10:07PM DBG Factory START with ns `"default"
10:07PM DBG Fetching latest k9s rev...
10:07PM DBG K9s latest rev: "v0.31.2"
10:07PM DBG No custom skin found. Using stock skin

If relevant, here is my k9s info:

 ____  __.________       
|    |/ _/   __   \______
|      < \____    /  ___/
|    |  \   /    /\___ \ 
|____|__ \ /____//____  >
        \/            \/ 

Version:           0.31.2
Config:            ~/Library/Application Support/k9s/config.yaml
Custom Views:      ~/Library/Application Support/k9s/views.yaml
Plugins:           ~/Library/Application Support/k9s/plugins.yaml
Hotkeys:           ~/Library/Application Support/k9s/hotkeys.yaml
Aliases:           ~/Library/Application Support/k9s/aliases.yaml
Skins:             ~/Library/Application Support/k9s/skins
Context Configs:   ~/Library/Application Support/k9s/clusters
Logs:              ~/Library/Application Support/k9s/k9s.log
Benchmarks:        ~/Library/Application Support/k9s/benchmarks
ScreenDumps:       ~/Library/Application Support/k9s/screen-dumps

Let me know, if you have any further questions.

[derailed]

@1nval1d Thank you for the great details!
I think this is a separate issue as the initial issue deals with the global config.yaml file and not the context specific config.yaml.

That said... What you've reported is indeed a bug ;(

[calmacroi]

@calmacroi Thanks for the details! Can you share the output of k9s info and attach your k9s debug logs? Tx! Also please watch for XDG setup: https://youtu.be/X3444KfjguE

@derailed : so my log file in debug logging on startup contains:

8:38AM INF 🐶 K9s starting up...
8:38AM DBG Found existing context config: "/Users/pkistler/Library/Application Support/k9s/clusters/SC@MTF/SC@MTF/config.yaml"
8:38AM DBG Active Context "SC@MTF"
8:38AM INF ✅ Kubernetes connectivity
8:38AM DBG No custom skin found. Using stock skin
8:38AM DBG Factory START with ns `"default"
8:38AM DBG Fetching latest k9s rev...
8:38AM DBG K9s latest rev: "v0.31.2"
8:38AM DBG No custom skin found. Using stock skin

using k9s info looks like:

Version:           0.31.2
Config:            /Users/USER/.config/k9s/config.yaml
Custom Views:      /Users/USER/.config/k9s/views.yaml
Plugins:           /Users/USER/.config/k9s/plugins.yaml
Hotkeys:           /Users/USER/.config/k9s/hotkeys.yaml
Aliases:           /Users/USER/.config/k9s/aliases.yaml
Skins:             /Users/USER/.config/k9s/skins
Context Configs:   /Users/USER/Library/Application Support/k9s/clusters
Logs:              /Users/USER/Library/Application Support/k9s/k9s.log
Benchmarks:        /Users/USER/Library/Application Support/k9s/benchmarks
ScreenDumps:       /Users/USER/Library/Application Support/k9s/screen-dumps

apparently the cluster specific configuration is not taking into account according the log/info output although changing the the k9s/view/active it is taken into account while changing k9s/namespace/active always gets reverted to value default in the file XDG_CONFIG/clusters/SC@MTF/SC@MTF/config.yaml:

k9s:
  cluster: SC@MTF
  readOnly: false
  namespace:
    active: default
    lockFavorites: true
    favorites:
    - all
    - development
    - prelive
    - live
  view:
    active: pod
  featureGates:
    nodeShell: false
  portForwardAddress: localhost

[derailed]

@calmacroi Thank you for the details!
I think I'll have a fix in the next drop.

[derailed]

@calmacroi Please give v0.31.3 a rinse and see if we're happier... Tx!

[calmacroi]

@calmacroi Please give v0.31.3 a rinse and see if we're happier... Tx!

the new version works as expected - thank you very much for the fast fix.