Does auto-update grab the original cloud-config file?

[Brian Buckley]

I have several CoreOS instances on GCE. I configure them with --metadata-from-file user-data=my-cloud-config.yaml

Last week, I found that I had the wrong hostname for one of my rabbit instances. So, I vi'd the .service file in /etc/systemd/system, did a systemctl daemon-reload, followed by systemctl restart myservice.service. All was well. Now I realize I shouldn't just be hacking on the service files as there are a million more elegant solutions, but it was production, I was in a hurry and it worked.

Until ...

When CoreOS did an auto-update, I found it restarted my docker service, as expected, but it seemed to reload the original configuration from my-cloud-config.yaml and did not preserve the ugly vi hack on the service file. The result? A hundred thousand messages backed up on Rabbit. Ugh. 

Is this normal behavior? When CoreOS updates, does it go back in time, grab the original cloud-config and discard any changes I might have manually of made in the .service files? And perhaps more importantly, the next time I do some misguided ugly service-file hack, do I need to hack it in both the service file and wherever GCE puts the original cloud-config.yaml file?

[Rob Szumski]

Yes, that’s normal behavior. On cloud-providers a fresh copy of the latest user-data is fetched from the metadata service. The ability to edit this while an instance is running differs between providers. I believe that EC2 doesn’t allow you to edit unless the instance is “stopped” but GCE does let you edit it at any time.

In your case, you have two options:

1. Edit the service/unit/file on disk _and_ in the GCE metadata service. Restart the service and you’re good to go.

2. Edit only the GCE metadata service and then reboot your machine to reprocess the file.

It basically depends on how much you want to interrupt other containers running on that host.

A quick note: cloud-init only touches files/settings specified in the cloud-config. If you wrote out some random files in /opt or something they wouldn’t be messed with at all during a reboot or OS update.

 - Rob

--
You received this message because you are subscribed to the Google Groups "CoreOS User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to coreos-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.