Comparison with existing Terraform provider

[tensor5]

Hi, I'm the developer of https://github.com/tensor5/terraform-provider-talos (released in the Terraform registry here). I was recently pointed by @frezbo to the existing #4, so I would like to analyze the differences between the two solutions.

First of all a little bit of history. I started developing my provider about a year ago because I really like the the core ideas behind Talos (minimality, immutability, ...), and wanted to use it personally. My main objective was to make it as easy as possible to deploy a Talos cluster, therefore I decided to develop a Terraform provider for it, and worked mainly on UX and usability. I made the first released in the Terraform Registry in January 2022, which only included the talos_bootstrap resource, and I recently made a second release that added the talos_gen_config resource.

Here are the main highlights of my provider

• it is already released to the Registry and has many downloads.
• resources and their options are named after the talosctl subcommands for clarity
• the talos_gen_config resource support all the relevant options of the corresponding command
• the talos_bootstrap resource bootstraps the cluster and outputs a ready to use kubeconfig
• the talos_kubeconfig data source retrieves the kubeconfig from an existing cluster
• real world ready-to-run examples, targeting DigitalOcean and OpenStack. Anyone can run those examples and see a Talos cluster up and running
• extensive use of GitHub Actions: Dependabot automerge, release automation with changelog generation, automatic binary generation and signing
• uses Nix to provide a reproducible developer environment
• it has a clear commit history.

Differences with #4:

• my provider has a single talos_gen_config resource for generating configs which mimics the corresponding talosctl subcommand for clarity. Instead #4 has two separate resources: talos_machine_configuration_controlplane and talos_machine_configuration_worker
• in #4 the talos_machine_configuration_controlplane and talos_machine_configuration_worker require machine secrets as input, while in my provider talos_gen_config generate machine secrets exacly like talosctl gen config does.

What is missing in my provider:

• automated tests, although it has been tested manually and it is released to the Terraform registry so anyone can run their own tests.

What is missing in #4:

• a resource to bootstrap the cluster
• a data source to retrieve the kubeconfig
• it is not released to the Terraform registry
• no release automation
• no real world examples.

What I plan to develop next:

• automated tests
• transition from the Terraform Plugin SDK to the Terraform Plugin Framework.

I would really like to join our efforts to deliver the best possible user experience for the Talos provider, therefore if you are interested I offer to pass the ownership of my provider to the SideroLabs org in the community interest, and continue working together on it. Adopting it would provide an official and already available and usable Terraform provider to the community.

Thank you.

PS: my comparison was inevitably biased, I would like to hear your opinions.

[frezbo]

the talos_gen_config resource support all the relevant options of the corresponding command

with the provider we want to move away from as much options as possible, since now we have strategic merges, it makes it easier to use things as a patch

my provider has a single talos_gen_config resource

this is something that have been changed on talos side also, users want secrets and config to be separated. This also means no need to re-create secrets when some inputs change, machine configuration is now completely reproducible

What is missing in https://github.com/siderolabs/terraform-provider-talos/pull/4:

a resource to bootstrap the cluster a data source to retrieve the kubeconfig it is not released to the Terraform registry no release automation no real world examples.

bootstrap, apply-config, and kubeconfig retrieval would be another set of changes, and that's the basic minimum we'd like to officially support. Any other use-case could be community driven.

We plan to release this using our internal build process once the basic required features are implemented.

Real world examples would mostly be community driven and would go under https://github.com/siderolabs/contrib/ since we already maintain some pulumi examples there.

[tensor5]

This also means no need to re-create secrets when some inputs change, machine configuration is now completely reproducible

That is correct, in fact talos_gen_config only runs during the "create" phase, update currently doesn't do anything, so secrets are not regenerated. The best thing would be to have a resource that transparently does gen config during the create phase, and apply-config during update when inputs change.

[sergelogvinov]

Usually terraform provider repeats API or CLI tools.

I've created one example how it can be used https://github.com/siderolabs/terraform-provider-talos/issues/11

Better to have two type of machineconfig result: raw-yaml and terraform native values. And use it in different cases.

[sergelogvinov]

This also means no need to re-create secrets when some inputs change, machine configuration is now completely reproducible

That is correct, in fact talos_gen_config only runs during the "create" phase, update currently doesn't do anything, so secrets are not regenerated. The best thing would be to have a resource that transparently does gen config during the create phase, and apply-config during update when inputs change.

We can generate config in provider initialization stage

provider "talos" {
// values
}

[frezbo]

Better to have two type of machineconfig result: raw-yaml and terraform native values.

The tf native is not values like a map[string]interface is currently not possible with the terraform sdk, it needs the terraform plugin go which is still in preview.

[frezbo]

Better to have two type of machineconfig result: raw-yaml and terraform native values.

The tf native is not values like a map[string]interface is currently not possible with the terraform sdk, it needs the terraform plugin go which is still in preview.

we plan to only support native yaml for now, anything else could be community PR's