Expose ADV library as a public package for external tooling

[mcanevet]

Context

I'm building a Tinkerbell-based bare-metal provisioning stack for Talos. One of the steps is writing a PlatformConfigSpec YAML to the MetalNetworkPlatformConfig key (0x0a) in the META partition at provisioning time (before Talos boots) so the metal platform driver can deliver network configuration on first boot.

This is done from a Tinkerbell Workflow action container running in HookOS, where the Talos gRPC API is not yet available. Direct block-device access is the only path.

The problem

The ADV library lives at internal/pkg/meta/internal/adv/talos and cannot be imported outside the Talos module. I'd like to build a small standalone tool (talos-meta-write) to write META keys from provisioning environments, but I can't reuse the library without reimplementing the ADV format ourselves.

There is already a project doing exactly this (https://github.com/cozystack/talos-meta-tool) but it reimplements the format.

The ask

Would you be open to moving (or re-exporting) the ADV package to a public path such as pkg/meta/adv/? This would allow external tools to write META keys correctly without duplicating the format logic, and without requiring the tool to live inside the Talos repo itself.

Alternatively, if hosting a small cmd/talos-meta-write binary inside the Talos repo is acceptable, I'd be happy to submit a PR for that instead.

[kvaps]

+1 from me. I'm the maintainer of talos-meta-tool — the project mentioned above. It started as a PoC where I had to reimplement the ADV format because the library lives under internal/. Exposing it as a public pkg/meta/adv/ would let external tooling write META keys correctly without duplicating the format, which is exactly the use case we hit when provisioning Talos nodes before the gRPC API is available (PXE/Tinkerbell-style flows). Happy to see this move forward.

[smira]

We can expose this as a library, but we already have imager/Image Factory as an API to produce images of Talos with any META values. This is a supported API. Using any library directly will be strictly unsupported.

[mcanevet]

Thanks for the quick response!

I'm familiar with Image Factory and it works great for producing base images, but my use case is specifically per-node network configuration (bond interfaces, DHCP operators, static IPs) that varies across every machine in the fleet. Generating a unique image per node at provisioning time would mean a multi-minute image generation round-trip for each machine before I can even start flashing, which doesn't fit a PXE/Tinkerbell flow where the goal is a single universal image that gets customized at provision time.

The META partition is exactly the right abstraction for this, it's designed to hold per-node platform configuration that survives installs and is separate from the image itself. Writing to it at provisioning time (before first boot) via a small action in the Tinkerbell workflow is the natural fit.

I'm happy to accept that using the library directly is unsupported. I just want to avoid maintaining a reimplementation that could silently diverge from the real format. Even a thin public re-export with a "no stability guarantees" notice would be sufficient. Alternatively, a cmd/talos-meta-write in the repo that I'd maintain upstream would keep the format logic in one place.

Would either of those options be acceptable?

[smira]

I don't want to have any commands in the Talos repo, but we could make the internal library public, but this is still painful to use, as Talos has tons of dependencies. We could make it an external library as well, I can look into it this week.

[smira]

Enjoy: https://github.com/siderolabs/go-adv :)