Open IvanovOleg opened 5 years ago
Exists in the terraform 0.12.2 as well
I've changed this line:
https://github.com/terraform-providers/terraform-provider-ignition/blob/cbc74835e76081caf05f1861e695b4eb8fbceffc/ignition/resource_ignition_config.go#L258
to:
return storage, fmt.Errorf("invalid file %q, unknown file id", c.files)
and to:
return storage, fmt.Errorf("invalid file %q, unknown file id", d.Get("files"))
to see content and the problem is that there are two files in d.Get("files")
, but only one file is in c.files
. Looks like the static content file doesn't appear in the cache at this point.
The reason of the issue is that terraform 0.12 resolves static and dynamic content on different stages. This means that there are two separate"globalcache" instances. So when the buildStorage function works, it tries to check the availability of static files stored in the schema with globalcache that holds only dynamic content files and fails. The same thing happens with the other types.
Why did you close the issue? It sounds like there’s still a defect here.
@seh Because I've found https://github.com/terraform-providers/terraform-provider-ignition/issues/12 that looks the same
also encounter the same issue in terraform 0.12.3 ...
Same issue with
Using a variable to assign ignition file content fails. Using the file() operation reading content from a file works.
I am having the same issue
Error: invalid systemd unit "d119185b0d6e25dcdbf0f4ee0d9ccc4c34505f45894f759680e663faae018aea", unknown systemd unit id
We're hitting this too with Terraform version 0.12.7 and provider version 1.1.0.
It used to be possible to work around these problems in 0.11-era Terraform versions by not doing a separate terraform plan and terraform apply \<plan>, but rather going straight through with terraform apply. Now, though, with Terraform's 0.12-era versions, we can't get this provider to work at all.
Best would be if this provider immediately failed with an error during terraform init, warning not to proceed with trying to use it. @alexsomesan, it looks like you've been the most active maintainer on this project recently, and worked through the Terraform version 0.12 transition. Have you found it to work for you? If not, what's your recommended course of action here?
Hi, same here:
data "ignition_config" "test" {
count = 3
files = [
data.ignition_file.hello.id,
]
filesystems = [
data.ignition_filesystem.data_fs.id,
]
}
data "ignition_filesystem" "data_fs" {
name = "data"
mount {
device = "/dev/xvdb"
format = "xfs"
}
}
data "ignition_file" "hello" {
filesystem = "foo"
path = "/hello.txt"
content {
content = "Hello World! ${var.some_content}"
}
}
Error: invalid filesystem "a8392bb17f2efcdafdd004bc8564e2601df2a6f05b23b791dd731ea42e5cc2a7", unknown filesystem id
terraform version
Terraform v0.12.7
+ provider.aws v2.7.0
+ provider.ignition v1.1.0
+ provider.template v2.1.2
This is now fixed for us using the latest provider:
ignition 1.2.0
On a side note, as stated by the docs, we had to use .rendered for ignition_config systemd units.
Terraform Version
Terraform v0.12.1
Affected Resource(s)
Please list the resources as a list, for example:
If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.
Terraform Configuration Files
Expected Behavior
Ignition config is created.
Actual Behavior
Debug Output
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.