v1.4.7

[Slessi]

Omni 1.4.7 (2026-01-06)

Welcome to the v1.4.7 release of Omni!

Please try out the release binaries and report any issues at
https://github.com/siderolabs/omni/issues.

Urgent Upgrade Notes (No, really, you MUST read this before you upgrade)

This release consolidates Discovery service state, Audit logs, Machine logs, and Secondary resources into a single SQLite storage backend.

1. New Required Flag
You must set the new --sqlite-storage-path (or .storage.sqlite.path) flag. There is no default value, and Omni will not start without it.
It must be a path to the SQLite file (will be created by Omni), not a directory, e.g., --sqlite-storage-path=/path/to/omni-sqlite.db.

2. Audit Logging Changes
A new flag --audit-log-enabled (or .logs.audit.enabled) has been introduced to explicitly enable or disable audit logging.

• Default: true.
• Change: Previously, audit logging was implicitly enabled only when the path was set. Now, it is enabled by default.

3. Automatic Migration
Omni will automatically migrate your existing data (BoltDB, file-based logs) to the new SQLite database on the first startup. To ensure this happens correctly, simply add the new SQLite flag and leave your existing storage flags in place for the first run.

Once the migration is complete, you are free to remove the deprecated flags listed below. If they remain, they will be ignored and eventually dropped in future versions.

4. Deprecated Flags (Kept for Migration)
The following flags (and config keys) are deprecated and kept solely to facilitate the automatic migration:

• --audit-log-dir (.logs.audit.path)
• --secondary-storage-path (.storage.secondary.path)
• --machine-log-storage-path (.logs.machine.storage.path)
• --machine-log-storage-enabled (.logs.machine.storage.enabled)
• --embedded-discovery-service-snapshot-path (.services.embeddedDiscoveryService.snapshotsPath)
• --machine-log-buffer-capacity (.logs.machine.bufferInitialCapacity)
• --machine-log-buffer-max-capacity (.logs.machine.bufferMaxCapacity)
• --machine-log-buffer-safe-gap (.logs.machine.bufferSafetyGap)
• --machine-log-num-compressed-chunks (.logs.machine.storage.numCompressedChunks)

5. Removed Flags
The following flags have been removed and are no longer supported:

• --machine-log-storage-flush-period (.logs.machine.storage.flushPeriod)
• --machine-log-storage-flush-jitter (.logs.machine.storage.flushJitter)

Contributors

• Edward Sammut Alessi
• Artem Chernyshev

Changes

4 commits

• ed9a9662 release(v1.4.7): prepare release
• e89f08b0 fix: set secureboot for image correctly from download modal
• 3a957d40 fix(frontend): allow selecting all download options for omnictl
• bffbb42d release(v1.4.6): prepare release

Dependency Changes

This release has no dependency changes

Previous release can be found at v1.4.6

---

This discussion was created from the release v1.4.7.

[macmandr197]

Hey there, I attempted to use Omni 1.4.7 with a cluster template to create a Talos cluster with v1.12.2, and K8s version 1.35.0. Within this cluster template, I would like Talos/Omni to handle the node name, and do not care to specify my own hostnames. Typically, if I have done this in the past, I would not specify anything.

I understand now, however, that a "hostnameconfig" patchis required within the cluster template. I have specified that the hostnameconfig autro value should be set to stable so that Omni will let the talos machine config generate itself. This patch is applied as follows

patches:
  - name: stable-auto-hostname
    inline:
      apiVersion: v1alpha1
      kind: HostnameConfig
      auto: stable

However, even after doing this, I still get the following error within Omni: configuration validation failed: 1 error occurred: * static hostname is already set in v1alpha1 config

How may I address this issue?

[smira]

This has nothing to do with Omni v1.4.7 (so please create separate issues/discussions).

You don't need to set stable explicitly, as it's a default, but you somewhere have legacy machine.hostname value set (config patch, provider?)

[macmandr197]

I think it does have something to do with Omni, or at the very least, talos? This is the cluster template I'm using, with the only patch file for my control plane:

For whatever reason, even with the hostnameconfig option specified, the node's network.hostname is still configured which results in the mentioned error. If after receiving this information, you still do not believe this has anything to do with Omni, can you please let me know where I should be headed? I already mentioned this in the Slack channel and was referred here.

template:

# omnictl cluster template sync -v -f cluster-template-working.yaml
---
kind: Cluster
name: labber
labels:
  cluster-id: "1"
kubernetes:
  version: v1.35.0
talos:
  version: v1.12.2
patches:
  - name: disable-default-cni
    inline:
      cluster:
        network:
          cni:
            name: none
        proxy:
          disabled: true
---
kind: ControlPlane
machineClass:
  name: proxmox-control-plane
  size: 1
systemExtensions:
  - siderolabs/iscsi-tools
  - siderolabs/nfsd
  - siderolabs/qemu-guest-agent
  - siderolabs/util-linux-tools
patches:
  - name: stable-auto-hostname
    inline:
      apiVersion: v1alpha1
      kind: HostnameConfig
      auto: stable
  - file: iac/omni/cluster-template/patches/control-plane.yaml
---
kind: Workers
name: workers
machineClass:
  name: proxmox-worker
  size: 3
systemExtensions:
  - siderolabs/iscsi-tools
  - siderolabs/nfsd
  - siderolabs/qemu-guest-agent 
  - siderolabs/util-linux-tools
patches:
  - name: stable-auto-hostname
    inline:
      apiVersion: v1alpha1
      kind: HostnameConfig
      auto: stable
  - name: worker-labels
    inline:
      machine:
        nodeLabels:
          node-role.kubernetes.io/worker: ""
  - file: iac/omni/cluster-template/patches/worker.yaml
  - name: longhorn-storage
    inline:
      machine:
        kubelet:
          extraMounts:
            - destination: /var/lib/longhorn
              type: bind
              source: /var/local/longhorn
              options:
                - bind
                - rshared
                - rw
---
kind: Workers
name: gpu-workers
machineClass:
  name: proxmox-intel-gpu-worker
  size: 0
systemExtensions:
  - siderolabs/iscsi-tools
  - siderolabs/nfsd
  - siderolabs/qemu-guest-agent
  - siderolabs/util-linux-tools
  - siderolabs/i915
  - siderolabs/intel-ucode
  - siderolabs/xe
patches:
  - name: stable-auto-hostname
    inline:
      apiVersion: v1alpha1
      kind: HostnameConfig
      auto: stable
  - name: worker-labels
    inline:
      machine:
        nodeLabels:
          node-role.kubernetes.io/worker: ""
  - file: iac/omni/cluster-template/patches/intel-gpu-worker.yaml
  - name: longhorn-storage
    inline:
      machine:
        kubelet:
          extraMounts:
            - destination: /var/lib/longhorn
              type: bind
              source: /var/local/longhorn
              options:
                - bind
                - rshared
                - rw

(control plane) patch

machine:
  network:
    nameservers:
      - *.*.*.*
      - 8.8.8.8
    interfaces:
      - deviceSelector:
          physical: true
        dhcp: true
        # VIP for control plane (shared across all control plane nodes)
        vip:
          ip: *.*.*.*
  features:
    hostDNS:
      enabled: true
      forwardKubeDNSToHost: false

[Slessi]

@macmandr197 What @smira means is that this issue is not specifically related to the 1.4.7 release of Omni, and we would prefer to keep the 1.4.7 discussion focused on issues related specifically to the Omni 1.4.7 release.

Not sure specifically the issue you are seeing, but could we move this to a new discussion? Would be better for us to follow up there

[macmandr197]

ah, gotcha.

Absolutely, my apologies.

[smira]

you're using a provider, so please report this issue to a provider repository, providers are known to have bugs like this for now. you can keep using Talos v1.11, or upgrade later