📢 📢 📢 The upcoming 0.9 and breaking changes

[dmacvicar]

Hi everyone. I guess I have made enough progress that I can start talking about it and planning the switch.

tl;dr: the upcoming version of the provider will break compatibility.

Background

When this provider was developed, the idea was to mimic a cloud experience on top of libvirt. Because of this, the schema was done as flat as possible, features were abstracted and some features like disks from remote sources were added as convenience.

The initial users of the provider were usually makers of infrastructure software who needed complex network setups. Lot of code was contributed which added complexity outside of its initial design.

So for long time I wanted to restart the provider under a new design principles where:

• HCL maps almost 1:1 to libvirt XML and therefore almost any libvirt feature can be supported
• Most of the validation work is left to libvirt which is already doing it
• No abstractions or extra features, and when they do, they should be designed in a way that are quite independent
• More consistency, for example, most libvirt APIs can be mostly separated in lifecycle (create, destroy) which map quite well to terraform resources, and then some query APIs, which map well to data sources. This was not the case how we implemented for example querying the IP addresses
• No unnecessary defensive code, for example, checking that a volume exist when referenced, is a problem that terraform solves if the ID is interpolated and libvirt solves with its own checks, if the volume is referenced by a hardcoded strings.

I knew 1.0 would never come in the current form.

The new provider

The new provider is based on the new plugin framework. This gives us some room for better diagnostics and better plans.

It makes definitions more verbose, but it also means we can implement any libvirt feature. Defaults work as long as they are defaults in libvirt.

Migration plan

The current plan is to replace the full implementation in a single commit and branch 0.8. New releases can be done of 0.8.x versions to add bugfixes, so people who rely on it have a path forward. I'd likely not maintain much of 0.8.x, but I guess many people will help here, as they do today with different PRs.

There is no automated way of migrating the HCL of previous providers, but given that it is documented how the new schema is defined, which was not the case with the previous schema, it should be much easier to drive LLMs to perform a conversion.

When

I think anytime in the next few weeks I can have the new provider in git for some early testing.

[srbarrios]

Awesome @dmacvicar! Thank you for this huge effort!
I wonder, did you make a try using OpenTofu instead of Terraform?
In our Uyuni team, we are moving to OpenTofu which has been fully transparent in our first attempts.

[dmacvicar]

@srbarrios the current codebase has a make testacc-tofu which runs the acceptance testsuite with tofu.

What I'd like to tackle next is to actually run the acceptance testsuite in Github actions. We did not until now as it requires nested virtualization, but I'd like to try the tcg accelerator now that seems to be used by libvirt.

In any case, I'd love to get input from your team as we make the new provider the default for everyone. I guess most people will end writing some modules to replace the higher level abstractions of the legacy one.

[dmacvicar]

In the main branch we now not only run the acceptance tests (using a hack to disable kvm and enable tcg, but those tests are not run in a matrix with both terraform and tofu.