Context: the new kubernetes node feature (Talos + Flatcar providers, #109) generates and holds the node config itself — cluster defs, join tokens, node images. My setup already runs Sidero Omni as the Talos control plane and source of truth (schematics, SideroLink, machine configs), so I don't want bootimus authoring a second, competing Talos config. I'd rather bootimus be the LAN PXE delivery layer for what Omni already produces.
Ask: an Omni-backed mode where bootimus pulls the image config Omni generates and serves it over PXE, instead of generating its own Talos config. Concretely — bootimus takes an Omni-issued schematic (id + Talos version), pulls the boot assets, and re-serves them via its own ProxyDHCP/TFTP/HTTP.
Why bootimus and not Omni's own boot endpoint: ProxyDHCP on the LAN (no DHCP reconfig), local caching so a node can still netboot when Omni or the factory is briefly unreachable, and one PXE server for everything on the network. Omni stays the control plane; bootimus is the delivery.
Technical notes, from tracing Omni + the image factory:
- Omni's installation-media exposes a "PXE boot (iPXE script)" preset. it resolves to an Image Factory URL of the shape
<factory-pxe>/pxe/<schematicId>/<talosVersion>/<platform>-<arch> (siderolabs/omni, frontend/src/views/InstallationMedia/usePresetDownloadLinks.ts).
- the Image Factory serves kernel, initramfs, kernel cmdline and the iPXE script per schematic+version (siderolabs/image-factory README).
- the schematic carries the SideroLink join args (Omni endpoint + join token) in the kernel cmdline, so the boot assets are self-contained: pull them, serve them, the node phones home to Omni on its own — no config generation needed on bootimus' side.
- so "image config from Omni" reduces to (schematic id + Talos version) -> plain-HTTP boot assets from the factory.
Open questions on the shape:
- input: does bootimus take the Omni-generated PXE URL directly (config/paste), or talk to the Omni API to enumerate schematics? URL-in is the minimal first cut.
- factory: support both the public factory.talos.dev and a self-hosted image-factory (configurable base URL, the way Omni carries an
image_factory_url).
- caching: fetch-and-cache kernel/initramfs locally vs chainload-through. the cache is the point — it's what survives a factory/Omni blip.
happy to work this into a PR if the direction's agreeable.
Context: the new kubernetes node feature (Talos + Flatcar providers, #109) generates and holds the node config itself — cluster defs, join tokens, node images. My setup already runs Sidero Omni as the Talos control plane and source of truth (schematics, SideroLink, machine configs), so I don't want bootimus authoring a second, competing Talos config. I'd rather bootimus be the LAN PXE delivery layer for what Omni already produces.
Ask: an Omni-backed mode where bootimus pulls the image config Omni generates and serves it over PXE, instead of generating its own Talos config. Concretely — bootimus takes an Omni-issued schematic (id + Talos version), pulls the boot assets, and re-serves them via its own ProxyDHCP/TFTP/HTTP.
Why bootimus and not Omni's own boot endpoint: ProxyDHCP on the LAN (no DHCP reconfig), local caching so a node can still netboot when Omni or the factory is briefly unreachable, and one PXE server for everything on the network. Omni stays the control plane; bootimus is the delivery.
Technical notes, from tracing Omni + the image factory:
<factory-pxe>/pxe/<schematicId>/<talosVersion>/<platform>-<arch>(siderolabs/omni,frontend/src/views/InstallationMedia/usePresetDownloadLinks.ts).Open questions on the shape:
image_factory_url).happy to work this into a PR if the direction's agreeable.