Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

Run terraform -v to show the version. If you are not running the latest version of Terraform, please upgrade because your issue may have already been fixed.

Affected Resource(s)

Please list the resources as a list, for example:

Ignition
Vsphere

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.

Debug Output

Please provider a link to a GitHub Gist containing the complete debug output: https://www.terraform.io/docs/internals/debugging.html. Please do NOT paste the debug output in the issue; just paste a link to the Gist.

Panic Output

If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log.

Expected Behavior

What should have happened?
Ignition configs generate

Actual Behavior

What actually happened?

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform plan -out

Important Factoids

Are there anything atypical about your accounts that we should know? For example: Running in EC2 Classic? Custom version of OpenStack? Tight ACLs?
This was working without issue until I updated to the most recent ignition.

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

• GH-1234

It would be nice to allow appending content to files rather than over-writing the existing content

The use case is to add environment variables to /etc/profile.env to set the HTTP_PROXY variable so the newly deployed OS can access the internet.

Is it possible to use this provider to set CoreOS etcd and locksmith settings? E.g. to implement the extra specification from https://coreos.com/os/docs/latest/configuration.html
The yaml version of what one might want to configure:

etcd:
  version:                     "3.0.15"
  name:                        "{HOSTNAME}"
  advertise_client_urls:       "http://{PRIVATE_IPV4}:2379"
  initial_advertise_peer_urls: "http://{PRIVATE_IPV4}:2380"
  listen_client_urls:          "http://0.0.0.0:2379"
  listen_peer_urls:            "http://{PRIVATE_IPV4}:2380"
  initial_cluster:             "{HOSTNAME}=http://{PRIVATE_IPV4}:2380"
update:
  group:  "beta"
locksmith:
  reboot_strategy: "etcd-lock"
  window_start:    "Sun 1:00"
  window_length:   "2h"

(examples are from CoreOS docs)

If I have to believe the CoreOS documentation their configuration transpiler actually converts the update configuration to a file (/etc/coreos/update.conf), but it would be nice if the provider would add support for it, as the CoreOS documentation says you have to configure these things in YAML, and doesn't specify the config file format.

This issue was originally opened by @alkar as hashicorp/terraform#15830. It was migrated here as a result of the provider split. The original body of the issue is below.

Terraform Version

v0.9.11

Terraform Configuration Files

resource "random_id" "x" {
  byte_length = 1
}

data "ignition_file" "x" {
  filesystem = "root"
  path       = "/x"

  content {
    content = "${random_id.x.hex}"
  }
}

data "ignition_systemd_unit" "x" {
  name    = "x.service"
  content = ""
}

data "ignition_config" "x" {
  files   = ["${data.ignition_file.x.id}"]
  systemd = ["${data.ignition_systemd_unit.x.id}"]
}

Expected Behavior

It should be able to apply from a saved plan.

Steps to Reproduce

Applying directly works:

$ terraform apply
data.ignition_systemd_unit.x: Refreshing state...
random_id.x: Creating...
  b64:         "" => "<computed>"
  b64_std:     "" => "<computed>"
  b64_url:     "" => "<computed>"
  byte_length: "" => "1"
  dec:         "" => "<computed>"
  hex:         "" => "<computed>"
random_id.x: Creation complete (ID: dg)
data.ignition_file.x: Refreshing state...
data.ignition_config.x: Refreshing state...

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

The state of your infrastructure has been saved to the path
below. This state is required to modify and destroy your
infrastructure, so keep it safe. To inspect the complete state
use the `terraform show` command.

State path:

However, applying from a saved plan file:

$ terraform plan -out sp && terraform apply sp
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

data.ignition_systemd_unit.x: Refreshing state...
The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed. Cyan entries are data sources to be read.

Your plan was also saved to the path below. Call the "apply" subcommand
with this plan file and Terraform will exactly execute this execution
plan.

Path: sp

<= data.ignition_config.x
    files.#:   "<computed>"
    rendered:  "<computed>"
    systemd.#: "1"
    systemd.0: "c3582dce636f921cdc80f72fd27057f1fd14bd0b2a656383e2da0de1b09d3d2c"

<= data.ignition_file.x
    content.#:         "1"
    content.0.content: "${random_id.x.hex}"
    content.0.mime:    "text/plain"
    filesystem:        "root"
    path:              "/x"

+ random_id.x
    b64:         "<computed>"
    b64_std:     "<computed>"
    b64_url:     "<computed>"
    byte_length: "1"
    dec:         "<computed>"
    hex:         "<computed>"


Plan: 1 to add, 0 to change, 0 to destroy.
random_id.x: Creating...
  b64:         "" => "<computed>"
  b64_std:     "" => "<computed>"
  b64_url:     "" => "<computed>"
  byte_length: "" => "1"
  dec:         "" => "<computed>"
  hex:         "" => "<computed>"
random_id.x: Creation complete (ID: Qg)
data.ignition_file.x: Refreshing state...
data.ignition_config.x: Refreshing state...
Error applying plan:

1 error(s) occurred:

* data.ignition_config.x: data.ignition_config.x: invalid systemd unit "c3582dce636f921cdc80f72fd27057f1fd14bd0b2a656383e2da0de1b09d3d2c", unknown systemd unit id

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

$ terraform apply sp
Failed to load backend: This plan was created against an older state than is current. Please create
a new plan file against the latest state and try again.

Terraform doesn't allow you to run plans that were created from older
states since it doesn't properly represent the latest changes Terraform
may have made, and can result in unsafe behavior.

Plan Serial:    0
Current Serial: 1

$ terraform plan -out sp && terraform apply sp
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

random_id.x: Refreshing state... (ID: Qg)
data.ignition_systemd_unit.x: Refreshing state...
data.ignition_file.x: Refreshing state...
data.ignition_config.x: Refreshing state...
No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, Terraform
doesn't need to do anything.

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

References

Possibly hashicorp/terraform#11518

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.

Don't know where the docs are so I'm opening this issue here:

https://www.terraform.io/docs/providers/ignition/d/filesystem.html

has create = true

Terraform Version

terraform v0.12.3

Affected Resource(s)

• All resources

Terraform Configuration Files

I have made an example repo for Terraform 0.11 which works (but may have issues as stated in #50): https://github.com/meyskens/tf-ignition-011
I ported the same codebase to Terraform 0.12 where this seems to always happens https://github.com/meyskens/tf-ignition-012-fail
The example is quite complex, this was because i wanted to investigate another issue. Happy to try to reproduce it on a simpler project if needed.

Expected Behavior

IDs be pulled out of the cache when being passed in igniton_config

Actual Behavior

Error: invalid file "c521f5d49123e48489100eaebf01a2b438653ada9d1a00839958076b85e2992d", unknown file id

  on baremetal/ignition.tf line 209, in data "ignition_config" "prometheus_worker":
 209: data "ignition_config" "prometheus_worker" {
[...]

Steps to Reproduce

1. terraform apply

Notes

I made an implementation that removes the cache in a PR. Not 100% sure this is the best approach to solve this issue. But it solved the bug for me. Happy to discuss this as this is a very breaking change.
#56

Terraform Version

0.10.6

Provider Version

v1.0.0

Affected Resource(s)

ignition_config

Expected Behavior

#2 is fixed

Actual Behavior

#2 is not fixed

References

• #2

This issue was originally opened by @jangrewe as hashicorp/terraform#13285. It was migrated here as part of the provider split. The original body of the issue is below.

Terraform Version

0.9.2

Affected Resource(s)

• ignition_file

Terraform Configuration Files

data "ignition_file" "kubectl" {
    filesystem = "root"
    path = "/opt/bin/kubectl"
    mode = "0755"
    source {
        source = "https://storage.googleapis.com/kubernetes-release/release/v${var.k8s_version}/bin/linux/amd64/kubectl"
    }
}

Expected Behavior

The file gets downloaded, not verified, and written to the specified path.

Actual Behavior

Error refreshing state: 1 error(s) occurred:

* module.kubernetes.data.ignition_file.kubectl: 1 error(s) occurred:

* module.kubernetes.data.ignition_file.kubectl: data.ignition_file.kubectl: malformed hash specifier

Steps to Reproduce

1. terraform plan

Important Factoids

The docs specify that verification is optional.

The Ignition config spec v2.1.0 PR #8 landed. I was wondering when it will appear on https://releases.hashicorp.com/terraform-provider-ignition/ for general usage?

Thanks for any hints and the hard work to make it happen!

/cc @alexsomesan @sym3tri

https://coreos.com/ignition/docs/latest/configuration-v2_1.html

New features:

• Downloads can come from S3 and TFTP
• Partitions can be referenced by GUID
• Additional file systems and swap devices can be created
• Directories and symlinks can be created

Changes:

• Filesystem create block is deprecated, new wipeFilesystem option instead
• systemd unit option renamed from enable to enabled for consistency

Once an Ignition version that supports this format reaches CoreOS Container Linux "stable", the provider should be updated to create v2.1 configs.

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

Terraform v0.11.7

Affected Resource(s)

Please list the resources as a list, for example:

• ignition_systemd_unit

Terraform Configuration Files

data "template_file" "sonarqube_service" {
  template = <<EOF
    [Unit]
    Description=Sonarqube Container
    After=docker.service
    Requires=docker.service

    [Service]
    TimeoutStartSec=0
    Restart=always
    ExecStartPre=-/usr/bin/docker stop %n
    ExecStartPre=-/usr/bin/docker rm %n
    ExecStartPre=/usr/bin/docker pull sonarqube:alpine
    ExecStart=/usr/bin/docker run --rm
      --name sonarqube \
      -p 9000:${SONARQUBE_HTTPPORT} \
      -p 9092:9092 \
      -e SONARQUBE_JDBC_USERNAME=${SONARQUBE_JDBC_USERNAME} \
      -e SONARQUBE_JDBC_PASSWORD=${SONARQUBE_JDBC_PASSWORD} \
      -e SONARQUBE_JDBC_URL=${SONARQUBE_JDBC_URL} \
      sonarqube:alpine

    [Install]
    WantedBy=multi-user.target
  EOF

  vars {
    # DB
    SONARQUBE_JDBC_USERNAME = "foo"
    SONARQUBE_JDBC_PASSWORD = "bar"
    SONARQUBE_JDBC_URL      = "jdbc:postgresql://localhost/sonarqube"

    # HTTP
    SONARQUBE_HTTPPORT = "8080"
  }
}

data "ignition_systemd_unit" "sonarqube" {
  name = "sonarqube.service"
  content = "${data.template_file.sonarqube_service.rendered}"
}

data "ignition_config" "sonarqube" {
  systemd = [
    "${data.ignition_systemd_unit.sonarqube.id}",
  ]
}

Debug Output

Error: Error refreshing state: 1 error(s) occurred:

* data.ignition_systemd_unit.sonarqube: 1 error(s) occurred:

* data.ignition_systemd_unit.sonarqube: data.ignition_systemd_unit.sonarqube: invalid configuration:
error: invalid unit content: unexpected newline encountered while parsing option name

Expected Behavior

The ignition config should have been created. Systemd unit file is kept multiline for better readability.

Actual Behavior

The systemd unit file is not been accepted, instead the ignition provider expects the string to be one single line with \n characters inside of it.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply

Ignition documentation for ignition_file and ignition_directory state that mode argument can be provided either octal or decimal:

mode - (Optional) The directory's permission mode. Note that the mode can be specified as either an octal value (e.g 0755) or a decimal value (i.e. 493 as equivalent to the octal 0755).

While provided values are evaluated as decimals only, even with leading 0. For example 0755 results with --wxrw--wx 0363 octal and 243 decimal.
Quick look at the code suggests that mode is evaluated as TypeInt.

Please either extend code, so both octal and decimal are evaluated correctly or update documentation to state that only decimal values are accepted.

Specs: https://coreos.com/ignition/docs/latest/configuration-v2_2.html
Migration: https://coreos.com/ignition/docs/latest/migrating-configs.html

Currently files are being base64 encoded and labelled with the following header: data:text/plain;charset=utf-8;base64,<value>

base64 encoding plaintext results in a larger byte count (important for AWS userdata)

for example our fairly standard kubernetes apiserver manifest has the following byte count:

plain - 2378
b64 - 3180
gzip+b64 - 1208

considering AWS allows up to 16KB pre base64'd data, gziping files would make a huge difference. A single file resource can save 2k!

the only "gotcha" I haven't looked into is whether ignition can parse base64gzip'd files.

Happy to work on a PR if the idea is sound.

Terraform Version

Terraform v0.11.2

• provider.ignition v1.0.0
• provider.vsphere v1.3.2

Affected Resource(s)

• provider.ignition v1.0.0

Terraform Configuration Files

N/A

Debug Output

N/A

Panic Output

N/A

Expected Behavior

When using ignition and there's an ignition configuration change, it seems reasonable to expect terraform plan & terraform apply to do a destroy and add instead of change. This expectation is based on the way ignition provisions the operating system, once on first boot.

Actual Behavior

Changes to the ignition configuration after the initial terraform apply appear to update the ignition configurations but the changes never propagate to the OS (CoreOS) as this is not how ignition operates. This causes an apply to appear successful while in reality the operation does nothing functionally.

Steps to Reproduce

1. terraform apply
2. Make any valid ignition change
3. terraform apply

Important Factoids

N/A

References

https://coreos.com/ignition/docs/latest/

Terraform Version

terraform --version
Terraform v0.11.11
+ provider.ignition v1.0.1
+ provider.null v2.0.0

Affected Resource(s)

Please list the resources as a list, for example:

• ignition_config

Terraform Configuration Files

https://github.com/captn3m0/ignition-bug-report

Debug Output

https://paste.ubuntu.com/p/grzKJn3P7D/

Expected Behavior

append should accept a list of maps from a variable.

Actual Behavior

Error: data.ignition_config.main: "append.0.source": required field is not set

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. git clone [email protected]:captn3m0/ignition-bug-report.git
2. cd ignition-bug-report
3. terraform init && terraform plan

The basic idea is to get

data "ignition_config" "main" {
  append = ["${module.name.conf}"]
}

working. But append doesn't like taking its value from a external source.

https://www.terraform.io/docs/providers/ignition/d/directory.html#mode says:

mode - (Optional) The list of partitions and their configuration for this particular disk..

But it's actually the file mode. I wanted to quickly submit a fix but I'm a bit unclear on the details like whether it only takes octal notion etc.

Terraform Version

Terraform v0.10.4

Affected Resource(s)

• ignition_systemd_unit

Terraform Configuration Files

data "ignition_systemd_unit" "init" {
  name    = "init.service"
  enable  = false
  content = "stuff"
}

Debug Output

https://gist.github.com/sstarcher/7ea0004e67ecc4a98c8849a809dcc9b6

Expected Behavior

What should have happened? The enable flag should work.

Actual Behavior

What actually happened? The enable flag does not work.

Steps to Reproduce

1. terraform plan

This issue was originally opened by @andrejvanderzee as hashicorp/terraform#16493. It was migrated here as a result of the provider split. The original body of the issue is below.

Hi there,

I am encountering this issue when using ignition_file when copying encrypted PKI assets.

Error: Error applying plan:

1 error(s) occurred:

• module.kubernetes.module.masters.aws_launch_configuration.master_conf: 1 error(s) occurred:

• aws_launch_configuration.master_conf: Error creating launch configuration: ValidationError: 1 validation error detected: Value 'XXXXXXXXX' at 'userData' failed to satisfy constraint: Member must have length less than or equal to 21847
  status code: 400, request id: 82919b36-bd60-11e7-8156-e1805ec22de2

$ terraform version
Terraform v0.10.8

This is one of the failing configs:

data "ignition_systemd_unit" "pki_decrypt" {

  name   = "decrypt-pki.service"
  enabled = true

  content = <<EOF
[Unit]
Description=decrypt pki assets
Before=kubelet.service
After=network.service

[Service]
Restart=on-failure
RemainAfterExit=yes
ExecStartPre=/usr/bin/rkt run \
  --uuid-file-save=/var/run/coreos/decrypt-pki.uuid \
  --volume=ssl,kind=host,source=/etc/kubernetes/ssl,readOnly=false \
  --mount=volume=ssl,target=/etc/kubernetes/ssl \
  --volume=dns,kind=host,source=/etc/resolv.conf,readOnly=true \
  --mount volume=dns,target=/etc/resolv.conf \
  --net=host \
  --trust-keys-from-https \
  ${var.awscli_rkt_image} --exec=/bin/bash -- \
    -ec \
    'echo Decrypting PKI assets; \
     shopt -s nullglob; \
     for encKey in /etc/kubernetes/ssl/*.pem.enc; do \
     echo Decrypting $encKey; \
     /usr/bin/aws \
       --region ${var.kms_region} kms decrypt \
       --ciphertext-blob fileb://$encKey \
       --output text \
       --query Plaintext \
     | base64 -d > $$$${encKey%.enc}; \
     done; \
     echo done.'
ExecStart=-/usr/bin/rkt rm --uuid-file=/var/run/coreos/decrypt-assets.uuid

[Install]
RequiredBy=kubelet.service
EOF
}

data "ignition_file" "pki_ca" {

	filesystem = "root"
	mode       = 0644
	path = "/etc/kubernetes/ssl/ca.pem.enc"

	content { 
		mime = "application/base64"
		content = "${var.pki_ca}"
	}
}

data "ignition_file" "pki_apiserver" {

	filesystem = "root"
	mode       = 0644
	path = "/etc/kubernetes/ssl/apiserver.pem.enc"

	content { 
		mime = "application/base64"
		content = "${var.pki_apiserver}"
	}
}

data "ignition_file" "pki_apiserver_key" {

	filesystem = "root"
	mode       = 0644
	path = "/etc/kubernetes/ssl/apiserver-key.pem.enc"

	content { 
		mime = "application/base64"
		content = "${var.pki_apiserver_key}"
	}
}

Hi!

https://github.com/dmacvicar/terraform-provider-libvirt supports interacting with ignition resources with this providers.

We used to test this by importing the provider, as you can see:
https://github.com/dmacvicar/terraform-provider-libvirt/blob/master/libvirt/provider_test.go#L20
https://github.com/dmacvicar/terraform-provider-libvirt/blob/master/libvirt/resource_libvirt_coreos_ignition_test.go#L15

We are trying to update all terraform-provider-libvirt to ~0.11.3, we can't anymore import this provider for testing they work together.

Before we remove support for ignition or the test, Is there a chance this provider upgrades to terraform 0.11.x?

Thanks!

Terraform Version

Terraform v0.12.1

Affected Resource(s)

Please list the resources as a list, for example:

• ignition_config

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

resource "tls_private_key" "ca" {
  algorithm = "${var.tls_algorithm}"
}

data "ignition_file" "sysctl-net-core" {
  filesystem = "root"
  path       = "/etc/sysctl.d/nc.conf"
  mode       = 420

  content {
    content = "net.core.somaxconn = 512"
  }
}

data "ignition_file" "ca-key" {
  filesystem = "root"
  path       = "${var.tls_directory}/ca-key.pem"
  mode       = 493

  content {
    content = "${tls_private_key.ca.private_key_pem}"
  }
}

data "ignition_config" "main" {
  files = [
    "${data.ignition_file.sysctl-net-core.id}",
    "${data.ignition_file.ca-key.id}",
  ]
}

tls_directory             = "/etc/ssl/certs/kubernetes"
tls_algorithm             = "RSA"
tls_validity_period_hours = 26280
etcd_disk_lun_number      = 1

variable "tls_algorithm" {}
variable "tls_validity_period_hours" {}
variable "etcd_disk_lun_number" {}
variable "tls_directory" {}

Expected Behavior

Ignition config is created.

Actual Behavior

data.ignition_file.sysctl-net-core: Refreshing state...

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create
 <= read (data resources)

Terraform will perform the following actions:

  # data.ignition_config.main will be read during apply
  # (config refers to values not yet known)
 <= data "ignition_config" "main"  {
      + files    = [
          + "84c1889315f23264eb059f6a0dea5b0c3c3c362bc274c33c249b640e4700c4f0",
          + (known after apply),
        ]
      + id       = (known after apply)
      + rendered = (known after apply)
    }

  # data.ignition_file.ca-key will be read during apply
  # (config refers to values not yet known)
 <= data "ignition_file" "ca-key"  {
      + filesystem = "root"
      + id         = (known after apply)
      + mode       = 493
      + path       = "/etc/ssl/certs/kubernetes/ca-key.pem"

      + content {
          + content = (known after apply)
        }
    }

  # tls_private_key.ca will be created
  + resource "tls_private_key" "ca" {
      + algorithm                  = "RSA"
      + ecdsa_curve                = "P224"
      + id                         = (known after apply)
      + private_key_pem            = (known after apply)
      + public_key_fingerprint_md5 = (known after apply)
      + public_key_openssh         = (known after apply)
      + public_key_pem             = (known after apply)
      + rsa_bits                   = 2048
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

tls_private_key.ca: Creating...
tls_private_key.ca: Creation complete after 0s [id=7bcfe6bcf6ac7e5db31e29fd75615c6512ff20ee]
data.ignition_file.ca-key: Refreshing state...
data.ignition_config.main: Refreshing state...

Error: invalid file "84c1889315f23264eb059f6a0dea5b0c3c3c362bc274c33c249b640e4700c4f0", unknown file id

  on ignition.tf line 21, in data "ignition_config" "main":
  21: data "ignition_config" "main" {

Debug Output

2019/06/19 22:35:36 [TRACE] EvalReadData: working on data.ignition_config.main
2019/06/19 22:35:36 [TRACE] GetResourceInstance: data.ignition_file.sysctl-net-core is a single instance
2019/06/19 22:35:36 [TRACE] GetResourceInstance: data.ignition_file.ca-key is a single instance
2019/06/19 22:35:36 [TRACE] Re-validating config for data.ignition_config.main
2019/06/19 22:35:36 [TRACE] GRPCProvider: ValidateDataSourceConfig
2019/06/19 22:35:36 [TRACE] EvalReadData: data.ignition_config.main configuration is complete, so reading from provider
2019/06/19 22:35:36 [TRACE] GRPCProvider: ReadDataSource
2019/06/19 22:35:36 [ERROR] <root>: eval: *terraform.EvalReadData, err: invalid file "84c1889315f23264eb059f6a0dea5b0c3c3c362bc274c33c249b640e4700c4f0", unknown file id
2019/06/19 22:35:36 [ERROR] <root>: eval: *terraform.EvalSequence, err: invalid file "84c1889315f23264eb059f6a0dea5b0c3c3c362bc274c33c249b640e4700c4f0", unknown file id
2019/06/19 22:35:36 [TRACE] [walkApply] Exiting eval tree: data.ignition_config.main
2019/06/19 22:35:36 [TRACE] vertex "data.ignition_config.main": visit complete
2019/06/19 22:35:36 [TRACE] dag/walk: upstream of "meta.count-boundary (EachMode fixup)" errored, so skipping
2019/06/19 22:35:36 [TRACE] dag/walk: upstream of "provider.ignition (close)" errored, so skipping
2019/06/19 22:35:36 [TRACE] dag/walk: upstream of "root" errored, so skipping
2019/06/19 22:35:36 [TRACE] statemgr.Filesystem: no original state snapshot to back up
data2019/06/19 22:35:36 [TRACE] statemgr.Filesystem: state has changed since last snapshot, so incrementing serial to 3
.2019/06/19 22:35:36 [TRACE] statemgr.Filesystem: writing snapshot at terraform.tfstate
ignition_config.main: Refreshing state...
2019/06/19 22:35:36 [TRACE] statemgr.Filesystem: removing lock metadata file .terraform.tfstate.lock.info

Important Factoids

If the files section of the ignition_config contains references on both static content files and dynamic content files, ignition_config fails. Second execution of the apply command works. If I comment static content or dynamic content file references separately, it works. Looks like ignition_config doesn't resolve dependencies correctly.

device = "/dev/disk/by-label/ROOT"

should be

device = "/dev/disk/by-partlabel/ROOT"

similar to #32 don't know if this is the correct place

This it the setup

Terraform Version

                                                                          1 ↵

Terraform v0.13.0

• provider registry.terraform.io/hashicorp/archive v1.2.2
• provider registry.terraform.io/hashicorp/aws v3.2.0
• provider registry.terraform.io/hashicorp/local v1.3.0
• provider registry.terraform.io/hashicorp/null v2.1.2
• provider registry.terraform.io/hashicorp/template v2.1.2
• provider registry.terraform.io/hashicorp/tls v2.1.1
• provider registry.terraform.io/terraform-providers/datadog v2.12.1
• provider registry.terraform.io/terraform-providers/gitlab v2.11.0
• provider registry.terraform.io/terraform-providers/ignition v1.2.1
  Run terraform -v to show the version. If you are not running the latest version of Terraform, please upgrade because your issue may have already been fixed.

Affected Resource(s)

Any ignition (or, anything really, as terraform errors out before doing any work)

Terraform Configuration Files

One of a bunch of version.tf files:

terraform {
  required_version = ">= 0.13"
  required_providers {
    ignition = {
      source = "terraform-providers/ignition"
    }
    template = {
      source = "hashicorp/template"
    }
  }
}

My provider.tf is untouched from 0.12:

provider "archive" {
  version = "~> 1.2.2"
  alias   = "default"
}

provider "ignition" {
  version = "~> 1.2.1"
  alias   = "default"
}

provider "template" {
  version = "~> 2.1.2"
  alias   = "default"
}

provider "aws" {
  version = "~> 3.2.0"
  alias   = "default"
  region  = var.region
  profile = "k8s"
}

provider "local" {
  version = "~> 1.3.0"
  alias   = "default"
}

provider "null" {
  version = "~> 2.1.2"
  alias   = "default"
}

provider "tls" {
  version = "~> 2.1.0"
  alias   = "default"
}

Debug Output

terraform plan output:

Error: missing provider provider["registry.terraform.io/hashicorp/ignition"].default

Expected Behavior

I would have expected it to actuallu use the already downloaded ignition provider.
The output of terraform init:

Initializing modules...

Initializing the backend...

Initializing provider plugins...
- Using previously-installed hashicorp/archive v1.2.2
- Using previously-installed hashicorp/tls v2.1.1
- Using previously-installed hashicorp/aws v3.2.0
- Using previously-installed terraform-providers/ignition v1.2.1
- Using previously-installed terraform-providers/gitlab v2.11.0
- Using previously-installed terraform-providers/datadog v2.12.1
- Using previously-installed hashicorp/local v1.3.0
- Using previously-installed hashicorp/null v2.1.2
- Using previously-installed hashicorp/template v2.1.2

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, we recommend adding version constraints in a required_providers block
in your configuration, with the constraint strings suggested below.

* terraform-providers/gitlab: version = "~> 2.11.0"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Actual Behavior

Errors out with the missing provider:

Error: missing provider provider["registry.terraform.io/hashicorp/ignition"].default

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform plan

As seen in the official configuration document. This would allow users to specify a user/group name.

Hi there,

I was using a clever bit of software to attach a second network interface.

Pre terraform 1.07, my "user_data" config looked like :

{
    "ignition": {
      "version": "2.0.0",
      "config": {}
    },
    "storage": {
      "files": [
        {
          "filesystem": "root",
          "path": "/opt/bin/smilodon",
          "contents": {
            "source": "https://github.com/UKHomeOffice/smilodon/releases/download/v0.0.4/smilodon-0.0.4-linux-amd64",
            "verification": {
              "hash": "sha512-5c802367af2d6f59d2fdf96e3d81b0fcde4eb77410b2a47b8831fd7adb52351af69d221cd594b63aa926050ddac102c5b0168b103d62143799078bc1b364c2f4"
            }
          },
          "mode": 777,
          "user": {},
          "group": {}
        },

However, now it looks like :

{
    "ignition": {
      "config": {},
      "timeouts": {},
      "version": "2.1.0"
    },
    "networkd": {
      "units": [
        {
          "contents": "[Match]\nName=eth1\n[Network]\nDHCP=yes\n[DHCP]\nUseDNS=false\nUseMTU=true\nSendHostname=true\nUseRoutes=true\nRouteMetric=512\n",
          "name": "20-eth1.network"
        }
      ]
    },
    "passwd": {},
    "storage": {
      "files": [
        {
          "filesystem": "root",
          "group": {},
          "path": "/opt/bin/smilodon",
          "user": {},
          "contents": {
            "source": "https://github.com/UKHomeOffice/smilodon/releases/download/v0.0.4/smilodon-0.0.4-linux-amd64",
            "verification": {
              "hash": "sha512-5c802367af2d6f59d2fdf96e3d81b0fcde4eb77410b2a47b8831fd7adb52351af69d221cd594b63aa926050ddac102c5b0168b103d62143799078bc1b364c2f4"
            }
          },
          "mode": 777
        },

This basically causes the instance to fail to attach the second interface in time, which means the whole cluster fails to come up.

Is there a way to order them? So that ignition happens first?

Is there also a way to revert to version 2.0.0?

Cheers,.
Ben

This issue was originally opened by @arunabhabanerjee as hashicorp/terraform#23640. It was migrated here as a result of the provider split. The original body of the issue is below.

Terraform Version

Terraform v0.11.14

• provider.external v1.2.0
• provider.ignition v1.2.0
• provider.null v2.1.2
• provider.template v2.1.2
• provider.vsphere v1.13.0

-->

...

Terraform Configuration Files

``// ID identifying the cluster to create. Use your username so that resources created can be tracked back to you.
cluster_id = "test"

// Domain of the cluster. This should be "${cluster_id}.${base_domain}".
cluster_domain = "test.lab.local"

// Base domain from which the cluster domain is a subdomain.
base_domain = "lab.loacal"

// Name of the vSphere server. The dev cluster is on "vcsa.vmware.devcluster.openshift.com".
vsphere_server = "10.55.138.36"

// User on the vSphere server.
vsphere_user = "[email protected]"

// Password of the user on the vSphere server.
vsphere_password = "password"

// Name of the vSphere cluster. The dev cluster is "devel".
vsphere_cluster = "dev"

// Name of the vSphere data center. The dev cluster is "dc1".
vsphere_datacenter = "BTM"

// Name of the vSphere data store to use for the VMs. The dev cluster uses "nvme-ds1".
vsphere_datastore = "datastore2"

// Name of the VM template to clone to create VMs for the cluster. The dev cluster has a template named "rhcos-latest".
vm_template = "rhcos-latest"

// The machine_cidr where IP addresses will be assigned for cluster nodes.
// Additionally, IPAM will assign IPs based on the network ID.
machine_cidr = "10.55.24.0/21"

// The number of control plane VMs to create. Default is 3.
control_plane_count = 3

// The number of compute VMs to create. Default is 3.
compute_count = 3

// URL of the bootstrap ignition. This needs to be publicly accessible so that the bootstrap machine can pull the ignition.
bootstrap_ignition_url = "http://10.55.1.5:8080/ignition/bootstrap.ign"

// Ignition config for the control plane machines. You should copy the contents of the master.ign generated by the installer.
control_plane_ignition = <<END_OF_MASTER_IGNITION
{"ignition":{"config":{"append":[{"source":"https://api-int.test.lab.local:22623/config/master","verification":{}}]},"security":{"tls":{"certificateAuthorities":[{"source":"data:text/plain;charset=utf-8;base64,LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURFRENDQWZpZ0F3SUJBZ0lJUU5BQXRDbmhUVkl3RFFZSktvWklodmNOQVFFTEJRQXdKakVTTUJBR0ExVUUKQ3hNSmIzQmxibk5vYVdaME1SQXdEZ1lEVlFRREV3ZHliMjkwTFdOaE1CNFhEVEU1TVRJd016RTBNVFF6T1ZvWApEVEk1TVRFek1ERTBNVFF6T1Zvd0pqRVNNQkFHQTFVRUN4TUpiM0JsYm5Ob2FXWjBNUkF3RGdZRFZRUURFd2R5CmIyOTBMV05oTUlJQklqQU5CZ2txaGtpRzl3MEJBUUVGQUFPQ0FROEFNSUlCQ2dLQ0FRRUF1Q3FDSy8xYUtOOTAKQUFTamxQTTZxaFY2SHlPWGtKaFZKYm1YQzErbUthMG9CbnNiUGN4WE14NkFROXhSMSt0djJveFl1Q0lBRlNNUwplb3pIa2cyS2VhU25mQTJYdHVkRGZnaklTNUdsQ3lPRTJ4ZXZrZ1dzU0VVQXV3TmlTTXRRWS9BTWt1YnMyK3VZCmRVQUxUMHhsZWkyUWhoaFN6OXN3allNNitnaUh5K2JZMDZjZmxkbjF0NG5aRGZFeUlENFNaR25WeDBmVzNNZ3QKdVRPU200Q1E0WWpUZDlQd1pKL0RUckpkNG9sVjZHQlNoSXFBSHh0elBiaWZwMjZaTnY5MjRrN2trMFhKUDI5Lwp3MEErWDRPVG1tdnY0RVQ2SVJISDZlMFp6TW9BUkpReVF1ekJMUFhqZ0VGMFBtRDAvS2ZBSFlEc25Rdklza3JICldJa3A3enc5a3dJREFRQUJvMEl3UURBT0JnTlZIUThCQWY4RUJBTUNBcVF3RHdZRFZSMFRBUUgvQkFVd0F3RUIKL3pBZEJnTlZIUTRFRmdRVTI4TEhRTUlMZkNhREVBUGhhcWg0MmpVZjZvUXdEUVlKS29aSWh2Y05BUUVMQlFBRApnZ0VCQUFuQ2dCME9saTl4cmszZkVUK2hCOE9hQWtuRncra2NGVHdGMDNaYS9HeDkydW8wcjJZNlI2bDB2Q1NuCml2VHhoRzBMeDhaTlNYMURlSkFRbDY2YjkrTHF2QVhqdDNqUFpnT1VzRnp5NVBYUnl4emRFMVNPNGRGQ2dZdUcKUHZTYTNObkJaU3JlV0N5Wkp2SWt5S3VjajZRZWhiN0ROUmlYSjJ4WkJSajUya2NGQ29LN1JQODlkNGI4ZlRkNQpjV0dhVDJYcDBsbmJyb0dRWUp2dklmVXZ1N21kdzJ4dUVxMGFFUTFkK00xUnB6eWVxbVRJNTBUcHcxMnBjbnVYCkJnNzI2NVZ3SUxhdVhTWWRxbklnTHJjZU1SejUxbnpaSFdMMHRBMjJMdWRJNE9uNkt0NlJLaXNTQlRsT0ZlYTAKTTQyOFBsVWkrTm9ENm0zUnpmVDhreXFTWS9rPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==","verification":{}}]}},"timeouts":{},"version":"2.2.0"},"networkd":{},"passwd":{},"storage":{},"systemd":{}}
END_OF_MASTER_IGNITION

// Ignition config for the compute machines. You should copy the contents of the worker.ign generated by the installer.
compute_ignition = <<END_OF_WORKER_IGNITION
{"ignition":{"config":{"append":[{"source":"https://api-int.test.lab.local:22623/config/worker","verification":{}}]},"security":{"tls":{"certificateAuthorities":[{"source":"data:text/plain;charset=utf-8;base64,LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURFRENDQWZpZ0F3SUJBZ0lJUU5BQXRDbmhUVkl3RFFZSktvWklodmNOQVFFTEJRQXdKakVTTUJBR0ExVUUKQ3hNSmIzQmxibk5vYVdaME1SQXdEZ1lEVlFRREV3ZHliMjkwTFdOaE1CNFhEVEU1TVRJd016RTBNVFF6T1ZvWApEVEk1TVRFek1ERTBNVFF6T1Zvd0pqRVNNQkFHQTFVRUN4TUpiM0JsYm5Ob2FXWjBNUkF3RGdZRFZRUURFd2R5CmIyOTBMV05oTUlJQklqQU5CZ2txaGtpRzl3MEJBUUVGQUFPQ0FROEFNSUlCQ2dLQ0FRRUF1Q3FDSy8xYUtOOTAKQUFTamxQTTZxaFY2SHlPWGtKaFZKYm1YQzErbUthMG9CbnNiUGN4WE14NkFROXhSMSt0djJveFl1Q0lBRlNNUwplb3pIa2cyS2VhU25mQTJYdHVkRGZnaklTNUdsQ3lPRTJ4ZXZrZ1dzU0VVQXV3TmlTTXRRWS9BTWt1YnMyK3VZCmRVQUxUMHhsZWkyUWhoaFN6OXN3allNNitnaUh5K2JZMDZjZmxkbjF0NG5aRGZFeUlENFNaR25WeDBmVzNNZ3QKdVRPU200Q1E0WWpUZDlQd1pKL0RUckpkNG9sVjZHQlNoSXFBSHh0elBiaWZwMjZaTnY5MjRrN2trMFhKUDI5Lwp3MEErWDRPVG1tdnY0RVQ2SVJISDZlMFp6TW9BUkpReVF1ekJMUFhqZ0VGMFBtRDAvS2ZBSFlEc25Rdklza3JICldJa3A3enc5a3dJREFRQUJvMEl3UURBT0JnTlZIUThCQWY4RUJBTUNBcVF3RHdZRFZSMFRBUUgvQkFVd0F3RUIKL3pBZEJnTlZIUTRFRmdRVTI4TEhRTUlMZkNhREVBUGhhcWg0MmpVZjZvUXdEUVlKS29aSWh2Y05BUUVMQlFBRApnZ0VCQUFuQ2dCME9saTl4cmszZkVUK2hCOE9hQWtuRncra2NGVHdGMDNaYS9HeDkydW8wcjJZNlI2bDB2Q1NuCml2VHhoRzBMeDhaTlNYMURlSkFRbDY2YjkrTHF2QVhqdDNqUFpnT1VzRnp5NVBYUnl4emRFMVNPNGRGQ2dZdUcKUHZTYTNObkJaU3JlV0N5Wkp2SWt5S3VjajZRZWhiN0ROUmlYSjJ4WkJSajUya2NGQ29LN1JQODlkNGI4ZlRkNQpjV0dhVDJYcDBsbmJyb0dRWUp2dklmVXZ1N21kdzJ4dUVxMGFFUTFkK00xUnB6eWVxbVRJNTBUcHcxMnBjbnVYCkJnNzI2NVZ3SUxhdVhTWWRxbklnTHJjZU1SejUxbnpaSFdMMHRBMjJMdWRJNE9uNkt0NlJLaXNTQlRsT0ZlYTAKTTQyOFBsVWkrTm9ENm0zUnpmVDhreXFTWS9rPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==","verification":{}}]}},"timeouts":{},"version":"2.2.0"},"networkd":{},"passwd":{},"storage":{},"systemd":{}}
END_OF_WORKER_IGNITION

// Set ipam and ipam_token if you want to use the IPAM server to reserve IP
// addresses for the VMs.

// Address or hostname of the IPAM server from which to reserve IP addresses for the cluster machines.
// ipam = "139.178.89.254"

// Token to use to authenticate with the IPAM server.
// ipam_token = "TOKEN_FOR_THE_IPAM_SERVER"

// Set bootstrap_ip, control_plane_ip, and compute_ip if you want to use static
// IPs reserved someone else, rather than the IPAM server.

// The IP address to assign to the bootstrap VM.
bootstrap_ip = "10.55.1.10"

// The IP addresses to assign to the control plane VMs. The length of this list
// must match the value of control_plane_count.
control_plane_ips = ["10.55.1.11", "10.55.1.12", "10.55.1.13"]

// The IP addresses to assign to the compute VMs. The length of this list must
// match the value of compute_count.
compute_ips = ["10.55.1.14", "10.55.1.15", "10.55.1.16"]
root:/home/arunabha/openshift/installer/upi/vsphere>
`hcl
...

### Debug Output
<!--
Full debug output can be obtained by running Terraform with the environment variable `TF_LOG=trace`. Please create a GitHub Gist containing the debug output. Please do _not_ paste the debug output in the issue, since debug output is long.

Debug output may contain sensitive information. Please review it before posting publicly, and if you are concerned feel free to encrypt the files using the HashiCorp security public key.
-->

### Crash Output
<!--
# terraform apply -auto-approve
data.ignition_systemd_unit.restart[1]: Refreshing state...
data.ignition_systemd_unit.restart[2]: Refreshing state...
data.ignition_systemd_unit.restart: Refreshing state...
data.ignition_file.hostname: Refreshing state...
data.ignition_systemd_unit.restart[0]: Refreshing state...
data.ignition_file.hostname[2]: Refreshing state...
data.ignition_systemd_unit.restart[0]: Refreshing state...
data.ignition_file.hostname[2]: Refreshing state...
data.ignition_file.hostname[1]: Refreshing state...
data.ignition_file.hostname[1]: Refreshing state...
data.ignition_file.hostname[0]: Refreshing state...
data.ignition_systemd_unit.restart[2]: Refreshing state...
data.ignition_file.hostname[0]: Refreshing state...
data.ignition_systemd_unit.restart[1]: Refreshing state...
data.ignition_file.static_ip[1]: Refreshing state...
data.ignition_file.static_ip[2]: Refreshing state...
data.ignition_file.static_ip[0]: Refreshing state...
data.ignition_file.static_ip[2]: Refreshing state...
data.ignition_file.static_ip: Refreshing state...
data.ignition_file.static_ip[0]: Refreshing state...
data.ignition_config.ign[1]: Refreshing state...
data.ignition_config.ign[2]: Refreshing state...
data.ignition_file.static_ip[1]: Refreshing state...
data.ignition_config.ign[0]: Refreshing state...
data.ignition_config.ign: Refreshing state...
data.ignition_config.ign[2]: Refreshing state...
data.ignition_config.ign[0]: Refreshing state...
data.ignition_config.ign[1]: Refreshing state...
data.vsphere_datacenter.dc: Refreshing state...
data.vsphere_datastore.datastore: Refreshing state...
data.vsphere_virtual_machine.template: Refreshing state...
data.vsphere_network.network: Refreshing state...
data.vsphere_network.network: Refreshing state...
data.vsphere_compute_cluster.compute_cluster: Refreshing state...
data.vsphere_virtual_machine.template: Refreshing state...
data.vsphere_network.network: Refreshing state...
data.vsphere_datastore.datastore: Refreshing state...
data.vsphere_virtual_machine.template: Refreshing state...
data.vsphere_datastore.datastore: Refreshing state...

Error: Error refreshing state: 3 errors occurred:
        * module.control_plane.data.ignition_config.ign: 3 errors occurred:
        * module.control_plane.data.ignition_config.ign[0]: data.ignition_config.ign.0: No valid JSON found, make sure you're using .rendered and not .id: invalid character 'c' after top-level value
        * module.control_plane.data.ignition_config.ign[1]: data.ignition_config.ign.1: No valid JSON found, make sure you're using .rendered and not .id: invalid character 'b' in literal false (expecting 'a')
        * module.control_plane.data.ignition_config.ign[2]: data.ignition_config.ign.2: No valid JSON found, make sure you're using .rendered and not .id: invalid character 'b' after top-level value


        * module.bootstrap.data.ignition_config.ign: 1 error occurred:
        * module.bootstrap.data.ignition_config.ign: data.ignition_config.ign: No valid JSON found, make sure you're using .rendered and not .id: invalid character 'b' after top-level value


        * module.compute.data.ignition_config.ign: 3 errors occurred:
        * module.compute.data.ignition_config.ign[0]: data.ignition_config.ign.0: No valid JSON found, make sure you're using .rendered and not .id: invalid character 'c' after top-level value
        * module.compute.data.ignition_config.ign[1]: data.ignition_config.ign.1: No valid JSON found, make sure you're using .rendered and not .id: invalid character 'e' after top-level value
        * module.compute.data.ignition_config.ign[2]: data.ignition_config.ign.2: No valid JSON found, make sure you're using .rendered and not .id: invalid character 'c' looking for beginning of value

-->

### Expected Behavior
<!--
terraform should able to deploy VM
-->

### Actual Behavior
<!--
terraform is unable to deply VM
-->

### Steps to Reproduce
<!--
Please list the full steps required to reproduce the issue, for example:
1. `terraform init`
2. `terraform apply -auto-approve`
-->

### Additional Context
<!--
Are there anything atypical about your situation that we should know? For example: is Terraform running in a wrapper script or in a CI system? Are you passing any unusual command line options or environment variables to opt-in to non-default behavior?
-->

### References
<!--
Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

- hashicorp/terraform#6017

-->

It's currently using indented JSON:
https://github.com/terraform-providers/terraform-provider-ignition/blob/master/ignition/resource_ignition_config.go#L122

This doesn't really help with readability, as Terraform logs the JSON blob with additional escaping, ruining the effect, plus raw Ignition configs aren't meant to be human-readable anyway. It does blow up the file size, though, and most cloud providers have a pretty tight size limit on metadata.

Hi

docs say it's optional: https://www.terraform.io/docs/providers/ignition/d/file.html#filesystem

But it's not:

* module.do-fra1-test.data.ignition_file.hostname: "filesystem": required field is not set

Also not documented what to set this to if you don't want/need to (re)configure the rootfs.
I've already tried root which seems to work. I'd suggest making that the default if not omitted.

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

Run terraform -v to show the version. If you are not running the latest version of Terraform, please upgrade because your issue may have already been fixed.

Terraform v0.12

Affected Resource(s)

Please list the resources as a list, for example:

• opc_instance
• opc_storage_volume

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.

Debug Output

Please provider a link to a GitHub Gist containing the complete debug output: https://www.terraform.io/docs/internals/debugging.html. Please do NOT paste the debug output in the issue; just paste a link to the Gist.

Panic Output

If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log.

Expected Behavior

What should have happened?

Actual Behavior

What actually happened?

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply

Important Factoids

Are there anything atypical about your accounts that we should know? For example: Running in EC2 Classic? Custom version of OpenStack? Tight ACLs?

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

• GH-1234

It seems to be missing.

https://github.com/terraform-providers/terraform-provider-ignition/blob/master/website/docs/d/config.html.md