yahoo-eng-team team mailing list archive

[Dan Watkins <daniel.watkins@xxxxxxxxxxxxx>]

cloud-init does now support vendor-data.

** Changed in: cloud-init
       Status: Triaged => Fix Released

** Changed in: cloud-init (Ubuntu)
       Status: Triaged => Fix Released

-- 
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/684804

Title:
  cloud-init should fetch image-data as well as user-data

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: cloud-init

  cloud-init should fetch data specific to the image (and the platform)
  prior to fetching user-data, and treat it the same way.

  It should be an objective of ubuntu cloud images that they will run on
  multiple cloud platforms without customization. As cloud platforms
  differ, if the image is not customized, it is necessary for the image
  to perform certain platform-specific operations on first boot. These
  tend to be image specific too. An example would be to map PV driver
  disks.

  Currently cloud-init sucks down and run a user-data script if supplied. It gets this by default by reading
    http://169.254.169.254/user-data
  Cloud platform providers cannot provide data there because there is no agreed format for user-data (i.e. not every user uses the MIME format ubuntu's cloud-init uses), meaning that (a) we would corrupt the user-data blob, and (b) even prepending another MIME part, we'd run into problems with bad MIME etc.

  It is suggested that instead cloud-init FIRST gets a user-data script from
     http://169.254.169.254/image-data
  or similar. This would be platform specific data (as opposed to instance specific data) that would be run first. This could do platform specific stuff (for instance, change UUID, use custom first password code, disable bits of udev, and so forth).

  Added to the end of the URL would be GET parameters describing the
  operating system type, release, etc. that could be used to help the
  platform provider interpret what they should send down (although this
  could form part of the metadata of the image itself, in a situation
  where a server is e.g. installed manually on a blank disk it won't be
  there).

  This should be a pretty trivial addition to cloud-init.

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