Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
amaol-vestas opened this issue Sep 10, 2024 · 3 comments

Comments

@amaol-vestas
Copy link

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
Copy link
Member

smira commented Sep 10, 2024

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
Copy link

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

@smira
Copy link
Member

smira commented Oct 31, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants