Is talos integration with cluster api a project that might have the risk of be decommissioned?

[amaol-vestas]

Hi @smira, hope to find you well,

In one of the previous issues that I can't find you mentioned that talos integration with cluster api is a low priority project.
We are thinking on using this framework in our production environments, but we identify as risk that low priority scope of the project, can you share if the project might have the risk of being decommissioned in the next 2 to 3 years?

Really appreciate any feedback on this.

Thanks,

António Oliveira

[smira]

We (Sidero Labs) will keep updating the providers, but we won't be working on new features for CAPI providers.

Due to various shortcomings of CAPI approach, we are focusing on the Omni projects.

[soostdijck]

Is there more info in the shortcomings you see in CAPI, perhaps a blog article? I'd love to know more.

[smira]

CAPI is more of a cloud-focused, update-by-replacing approach built specifically for regular Linux distros running e.g. in AWS.

Talos Linux provides both in-place updates (configuration changes) and in-place upgrades which are fundamentally incompatible with CAPI.

If you use some cloud provider (like AWS) you might not care about in-place updates, but if you go bare-metal or any environment where data is persisted on the machine disks (not on external network volumes), you want any updates to be in-place.

CAPI has almost non-existent hybrid cluster support (using different infrastructure providers). (At least that was the case some time ago).

You can pick the approach that is the best fit for your scenario, and none of the options are perfect, so ymmv.

[nicklasfrahm]

In-place updates and upgrades have recently gotten some love and there is some documentation that is soon to be merged as part of kubernetes-sigs/cluster-api#9489 and kubernetes-sigs/cluster-api#11029.