🐛 Selecting "New Cluster" causes distro section of configfile to be overwritten

[cloudymax]

Describe the Bug

As a user with a k3s config that has lots of kubelet args, I prefer to configure all of them via the config file like so:

# which distros of Kubernetes to deploy. Options: kind, k3s, k3d
# NOTE: only kind and k3d are available on macOS at this time
k8s_distros:
  k3s:
    # set to true to enable deploying a Kubernetes cluster using k3s
    enabled: true
    # if k8s_distro set to k3s/k3d, you can add an array of extra arguments to pass
    # to the k3s install script as a k3s.yaml file. If you enable cilium, we
    # automatically pass in flannel-backend: none and disable-network-policy: true
    k3s_yaml:
      # if you enable MetalLB, we automatically add servicelb to the disable list
      # enables encryption at rest for Kubernetes secrets
      secrets-encryption: true
      node-external-ip: 100.64.0.1
      # disables traefik so we can enable ingress-nginx, remove if you're using traefik
      disable:
      - traefik
      - servicelb
      node-label:
      - ingress-ready=true
      kubelet-arg:
      - max_pods=150
      - node-ip=192.168.50.100
      - cpu-manager-policy=static
      - kube-reserved=cpu=1,memory=2Gi,ephemeral-storage=1Gi
      - system-reserved=cpu=1,memory=2Gi,ephemeral-storage=1Gi
    nodes:
      control_plane: 1
      workers: 0

When I launch the TUI and select "New Cluster", my config file is overwritten to the following:

# which distros of Kubernetes to deploy. Options: kind, k3s, k3d
# NOTE: only kind and k3d are available on macOS at this time
k8s_distros:
  k3s:
    # set to true to enable deploying a Kubernetes cluster using k3s
    enabled: true
    # if k8s_distro set to k3s/k3d, you can add an array of extra arguments to pass
    # to the k3s install script as a k3s.yaml file. If you enable cilium, we
    # automatically pass in flannel-backend: none and disable-network-policy: true
    k3s_yaml:
      # if you enable MetalLB, we automatically add servicelb to the disable list
      # enables encryption at rest for Kubernetes secrets
      secrets-encryption: true
      node-external-ip: 100.64.0.1
      # disables traefik so we can enable ingress-nginx, remove if you're using traefik
      disable:
      - traefik
      node-label:
      - ingress-ready=true
      kubelet-arg:
      - max_pods=150
    nodes:
      control_plane: 1
      workers: 0

However there is no issue if only using the cli

Steps to Reproduce Bug

1. add some kubelet args to your config file
2. launch the tui
3. select "New Cluster"
4. Exit the TUI
5. Inspect your config file

Expected behavior

I would assume that the data from the config file would be loaded into the tui on init

User info (please complete the following information):

• OS release: Debian12
• Kubernetes distro: k3s
• Version of smol-k8s-lab: v2.0.0
• Config file contents: see above

[jessebot]

Thanks for reporting this! I'll take a look tonight!

[jessebot]

fixing in #133

[cloudymax]

Unfortunately it's only mostly fixed, options that contain more than one comma get split prematurely:|

# which distros of Kubernetes to deploy. Options: kind, k3s, k3d
# NOTE: only kind and k3d are available on macOS at this time
k8s_distros:
  k3s:
    # set to true to enable deploying a Kubernetes cluster using k3s
    enabled: true
    # if k8s_distro set to k3s/k3d, you can add an array of extra arguments to pass
    # to the k3s install script as a k3s.yaml file. If you enable cilium, we
    # automatically pass in flannel-backend: none and disable-network-policy: true
    k3s_yaml:
      # if you enable MetalLB, we automatically add servicelb to the disable list
      # enables encryption at rest for Kubernetes secrets
      secrets-encryption: true
      node-external-ip: 100.64.0.1
      # disables traefik so we can enable ingress-nginx, remove if you're using traefik
      disable:
      - traefik
      - servicelb
      node-label:
      - ingress-ready=true
      kubelet-arg:
      - max_pods=150
      - node-ip=192.168.50.100
      - cpu-manager-policy=static
      - kube-reserved=cpu=1
      - memory=2Gi
      - ephemeral-storage=1Gi
      - system-reserved=cpu=1
      - memory=2Gi
      - ephemeral-storage=1Gi
    nodes:
      control_plane: 1
      workers: 0

• kube-reserved and system-reserved have a non-standard format that gets broken if it's split prematurely.

[jessebot]

ok, so this is going to require a second section for kubelet args to get this under control for k3s. Allow me a day or so to work on this as I need to add a tab to the k3s tui screen to fix this.

[jessebot]

ok, I've got most of this done in #135. I just need to fix this add new k3s option button and figure out another bug with the kubelet args duplicating. See screenshots below for current status:

[jessebot]

ok, fixed that issue, now just need to fix an issue to allow there to be multiple distros enabled at once, as right now, we assume you're launching either one cluster, or many clusters using kind or k3d. I want to add k8s_distros.selected:

k8s_distros:
  selected: "kind"

and then we can use the "selected" field, instead of the k8s_distros.DISTRO.enabled field, as the selected is really just for the current operations via the tui or cli, and enabled is relative to the OS (e.g. k3s doesn't work on macOS yet). After that's fixed, I'll regenerate screenshots and cut a new release :)

[jessebot]

ok, fixed that issue, now just need to fix an issue to allow there to be multiple distros enabled at once, as right now, we assume you're launching either one cluster, or many clusters using kind or k3d. I want to add k8s_distros.selected:

k8s_distros:
  selected: "kind"

and then we can use the "selected" field, instead of the k8s_distros.DISTRO.enabled field, as the selected is really just for the current operations via the tui or cli, and enabled is relative to the OS (e.g. k3s doesn't work on macOS yet). After that's fixed, I'll regenerate screenshots and cut a new release :)

so scratch this, I don't actually think it's necessary :) The issue was actually that I was querying a widget incorrectly after using multiple times. I was using self.query_one when I needed to use self.get_widget_by_id because we use the same kubelet widget for all distros now. Just finishing up testing now!