terraform-provider-matchbox, support for ignition files

[mcuadros]

Feature Request

The new terraform-provider-matchbox, doesn't support Ignition files, only supports CL config files.

Desired Feature

Support ignition files, ir order to be able to use the built-in ignition provider.
The extension of the InigitionId file at the profile is hardcode with the suffix .yaml.tmpl

[dghubble]

Supporting Container Linux Configs only was by design. Container Linux Configs are human readable, human writable, and made to be processed through tools which do validations for humans (return line numbers where errors occur, etc). Ignition configs are the machine representation and are more of an internal detail.

Is there a reason you cannot use a Container Linux config?

[mcuadros]

As described in the issue, I want to use the:
https://www.terraform.io/docs/providers/ignition/index.html

Since Container Linux config file is designed for user, I don't find any reason to change the ignition provider to generate Container Linux config, Since the interface to manipulate a ignition file is the provider.

[dghubble]

I'd rather see a Container Linux Config Terraform Provider validating with ct. The Container Linux config transpiler performs useful semantic checks and returns errors for humans to read (wrong unit for disk size, error in a particular section, etc). I'm less keen on terraform users trying to write a description of a config which is intended to be consumed by machines. Especially when we have a config for humans to write (or describe).

https://github.com/coreos/terraform-provider-ct is an example of a project which accepts Container Linux configs directly and validates them with ct. I think an improvement of that project would be to also allow users to describe each section of the Container Linux Config in terraform.

[dghubble]

Another aim is that terraform-provider-matchbox, as a fresh project, just supports the recommended config we'd like users to input, so there is no user confusion. For example, I've held out on adding Cloud-Config support for the same reason, though it would have been simple to add. Raw Ignition and Cloud-config are technically supported by Matchbox, but adding them to the provider isn't a decision that is easily undone.

[mcuadros]

Using Container Linux Config as a communication format looks an error, as you say is made for the users.

About https://github.com/coreos/terraform-provider-ct, using files instead of building the configuration with Terraform enters in conflict with the ability to organize your code and split it in logical units. Also makes extremely hard work with variables, since you are dealing with an interpolation system in a file instead of using the variables directly in the data resources.

[dghubble]

I think an improvement of that project would be to also allow users to describe each section of the Container Linux Config in terraform.

[mcuadros]

Yep, and this is exactly what you have at the ignition provider. Also is something that is being use since months, tested and debugged.

[dghubble]

They look similar, but are not the same. I'd prefer terraform users use Terraform to build a Container Linux config, rather than using Terraform to build a raw Ignition config. I'm anticipating Ignition becoming more of an internal implementation detail in future, with the Container Linux Config being the human friendly format users and clients input to Container Linux. terraform-provider-matchbox is a client.

I'll check with a few others to see if those plan have changed at all.

[dghubble]

Hey @mcuadros, seems like consensus is that its not too harmful to allow raw ignition to be passed by those who want it.

However, passing Container Linux Config's is the approach we recommend and the one we'll show in documentation and examples. Passing raw Ignition will get a passing mention since it circumvents the usual flow which enforces configs go through ct (binary or package) - users will get machine error reports, not pretty human error reports.

[mcuadros]

Implemented at poseidon/terraform-provider-matchbox@011ced7