The provider should be versioned and support multiple Ignition versions

[ajeddeloh]

Terraform Version

Any

Affected Resource(s)

• ignition_*

Brief Background about Ignition

First note: Ignition and the Ignition spec are versioned separately. Ignition versions have been in the 0.x.y series and the Ignition spec has been v1, v2.0.0, v2.1.0, v2.2.0, and v2.3.0.

Ignition also supports old config versions (you can hand a v1 config to Ignition today).

We're working on an Ignition v2.0.0 release (yes, skipping v1.x.y) with spec version 3.0.0. This is a hard break and not backwards compatible. Ignition v2.0.0 will not accept configs < spec 3.0.0.

Container Linux will stay on the v0.x (supporting up to spec 2.3.0) version for the rest of it's life. Fedora CoreOS will start with Ignition v2.0.0 (supporting spec 3.0.0+ but not older).

Problem:

These types should be versioned. At the very least there needs to be a separate provider (or a provider that supports both) for spec <= 2.3.0 and spec >= 3.0.0 so that Fedora CoreOS and Container Linux can both have providers. Ideally, each version would have it's own provider so users can update their configuration at their own pace. Furthermore, any time a spec has a major version update, fields may move or disappear, so terraform configs using that would break.

I'm not super familiar with terraform and not sure the best way to go about this. It's my understanding that terraform providers all share the same namespace. Given that, it probably makes sense to include the version in the names of the fields (e.g. ignition3_0_config or similar). If you have other suggestions please let me know.

[DanyC97]

@alexsomesan do you have any thoughts on this?

if is too complex to version the template etc maybe we can create a new provider like terraform-provider-ignition-v3 ?

i know it sounds silly but better to have some progress rather than nothing ?