feat: add static registry to talosctl

[shanduur]

talosctl includes two new subcommands talosctl image registry create and talosctlimage registry serve.

• talosctl image registry create allows creating a local OCI image registry containing Talos images for speeding up installations, upgrades, and deployments in air-gapped environments.

• talosctl image registry serve allows serving the created OCI image registry over HTTP. It is a read-only registry, meaning images cannot be pushed to it, but the backing storage can be updated by re-running the create command.

Fixes #11928
Fixes #11929

Signed-off-by: Mateusz Urbanek [email protected]

[smira]

I think we should find a signature for the exactly same digest as we mirror, to close the gap between resolving a tag and fetching a signature

[shanduur]

I think I've fixed it to what you've meant.

[smira]

As another question more higher level:

• we already have image pull process for image cache
• we already have registryd which can serve such image cache as a registry

Do we need to pull another/incompatible way with olareg? Can we unify both paths?

With image cache e.g. we already solved the problem of running on non-Linux and being able to handle paths with something like foo.bar:5000

[shanduur]

registryd is not OCI compatible and I'm not sure how to test it (even manually) - I can't just crane pull from it - we need a custom client for tests. This might cause friction for users in the future. Additionally registryd is not able to handle multi-arch manifests as of now, which are required for image factory (unless we don't want to distribute image factory using the cache). Olareg is just compliant plug-and-play option.

[shanduur]

Alternative approach using image cache and registryd: #12014

[smira]

registryd is not OCI compatible and I'm not sure how to test it (even manually) - I can't just crane pull from it - we need a custom client for tests. This might cause friction for users in the future. Additionally registryd is not able to handle multi-arch manifests as of now, which are required for image factory (unless we don't want to distribute image factory using the cache). Olareg is just compliant plug-and-play option.

I think registryd is dumb enough that it doesn't care what it serves :) So it should serve multi-arch as long as the directory contains multi-arch.

If crane fails to pull from it, we could try to fix it?

But my point is not to have two implementations, but rather just one (if we can).