Join GitHub today
failed to fetch config: not a config (empty) when using terraform #2456
I first thought that this might be a bug of terraform like reported in terraform-providers/terraform-provider-digitalocean#100, but after investigating a bit further it seems that the ignition file is actually properly supplied to the Droplet.
This is my ignition file
If I supply it as
If I supply it via
This is the output from
This is the output from
If I ssh into the droplet and curl
So in theory this should work, but it doesn't.
Hi! Thanks for the report. Unfortunately, I can't seem to reproduce this issue. I used your issue on
I left out the
Then I just used
Thanks for your quick reply.
Your config worked for me as well. So I took another look at my terraform config to see what might be causing the issue and I think its the Following:
I first build an image based on coreos-beta with packer
Instead of than using
Is it possible that I can only ever supply
What I am basically trying to do is to make the droplet creation faster by doing some configuration in the packer image. I initially had two ignition files, one for packer and one for terraform. The packer ignition file made general changes to the system which would apply to all droplets. The terraform ignition file initiated the etcd cluster. I couldn't add the etcd part to the packer ignition file as the IP of the droplet which is used by packer to build the image shouldn't be added to etcd and the IPs are only known after a droplet has been created through terraform. I think that the second ignition file supplied through terraform was never applied so thats why I moved all over to terraform.
It seems that in the combination of using
I don't have experience with packer, but from my understanding of what you are saying, it sounds like you are provisioning a CoreOS machine with packer, which then takes a snapshot of the resulting machine, and lets you boot from that snapshot?
Ignition only runs once on a particular machine, only on the very first boot. After that, if you make changes to your ignition config and want them applied to your machine, you have to reprovision it from scratch. If packer is provisioning a machine, then terraform is using that already provisioned machine, ignition will never run again, and so no ignition configuration that you provide later will ever be applied.
Most of the time,
Ran into this and came across this issue as well as #2090. It's not perfect but it seems like the following workaround causes Ignition to run as expected the second time:
sudo touch /boot/coreos/first_boot sudo rm /etc/machine-id
When I encountered this I was building an image (for AWS) with Packer. I wasn't provisioning that image with Ignition but hit this anyway when provisioning via Terraform/
I haven't had a chance to track down why it's parsed as an empty response resulting in the confusing error.