yahoo-eng-team team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

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.


** Changed in: cloud-init
   Importance: Undecided => Low

** Changed in: cloud-init
       Status: New => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1263893

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

Status in Init scripts for use on cloud images:
  Won't Fix

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1263893/+subscriptions