cloud-init-cfg doesn't run when user-data is not a cloud-config

[Mike Hommey]

STR:
- Take the Ubuntu Precise EC2 AMI and prepare an instance out of it.
- On that instance, set user-data to something that is not a cloud-config, not mime-encoded and not a few bytes.[1][2]
- Start the instance

Expected result:
- The instance is reachable by ssh.

Actual result:
- It's not reachable. Console output ends with "__init__.py[WARNING]: Unhandled non-multipart userdata (...)"
- /var/log/cloud-init.log shows that a boot leading to a reachable instance has logs messages about cloud-init-cfg, but a boot leading to an unreachable instance doesn't.

1. In my case "foo=bar" doesn't cause the problem, but "name=glandium-builders" does.
2. Note in my case I've been stopping and restarting an instance with different values for user-data, so it might actually not happen on the first boot, I don't know for sure, as the initial user-data for my instance was empty, and I already spent too much time tracking this problem.

[Scott Moser (smoser)]

Hi,
  As it is right now, instance-id is used to indicate whether or not something has run.
  So if you've stopped the instance, and then re-started it, it will believe that it has already processed user-data and wont act on it again. Thats not completely true, but thats the gist. Essentially, cloud-init doesn't handle changing user-data.
  If you want to shut an instance down, and have it fully re-run, you can rm -Rf /var/lib/cloud .

  So as far as I can tell, this is "working as designed". If you feel differently, or have ideas on a different and backwards compat mode of operation, feel free to re-open, and give your thoughts.

  Thank you for taking the time to open a bug.

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/2421