Upgrade talos/k8s via config file

[kaerbr]

So coming from kubernets, let's say I have this manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: alpine
spec:
  selector:
    matchLabels:
      app: alpine
  template:
    metadata:
      labels:
        app: alpine
    spec:
      containers:
      - name: alpine
        image: alpine:3.11

To update my deployment I would update alpine:3.11 to alpine3.12 and using kubectl apply -f ./my-manifest.yaml apply it.

---

For talos on the other hand: Let's say I have this (stripped down) controlplane.yaml:

machine:
  install:
    disk: /dev/sda
    image: ghcr.io/siderolabs/installer:v1.10.1

My naive approach would be to update the config file: ghcr.io/siderolabs/installer:v1.10.1 to ghcr.io/siderolabs/installer:v1.10.2 apply the config using talosctl apply-config -n <my-node> -e <my-endpoint> and therefore the node would update itself to the given version.

Unfortunately(?) this does not work and I have to use talosctl upgrade --nodes <my-node> -e <my-endpoint> --image ghcr.io/siderolabs/installer:v1.10.2. The same applies to k8s version upgrades.

The amount of workload is that same but I dont understand why I cannot use my naive approach.
What are the backgrounds to this decission?

In discussion #10796 there was the question how to metigate this behaviour but my question is more on the "why" this decision was made this way.

I hope someone can help me clear my mind on this topic. (:

[smira]

There are many reasons for it, but let me try to put something very simple: there is a subtle difference between explicit actions (API calls) and reconciling changes (e.g. machine config).

For Talos, it was a challenge to pick whether one should be an action (API call) or a config change that Talos automatically reconciles.

Let's take reboot as an example:

• can we make it an API call?
• can we make it a change that is reconciled (e.g. bumping some counter in the machine config)?

Both are possible, but today reboot is an API call, and that makes sense, as reboot is a single-time action which might carry some parameters (do I want to quick reboot, full reboot via firmware, etc.).

Upgrade/install is similar - you can e.g. potentially install to a different disk, change the bootloader. Sometimes you don't need to install at all - e.g. booted via a disk image. What if your machine is PXE-booted and totally ephemeral (all data in tmpfs)? What would a machine config for .machine.install mean? What would an upgrade mean?

So all in all, .machine.install I think was a mistake in the first place, and Install/Upgrade should be an API (#10950).