yahoo-eng-team team mailing list archive

[James Falcon <1888822@xxxxxxxxxxxxxxxxxx>]

This bug is believed to be fixed in cloud-init in version 20.3. If this
is still a problem for you, please make a comment and set the state back
to New

Thank you.

** Changed in: cloud-init
       Status: In Progress => 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/1888822

Title:
  cloud-init does not respect declared MIME types in multipart archives

Status in cloud-init:
  Fix Released

Bug description:
  In https://github.com/canonical/cloud-init/pull/290 we landed a change
  to user-data processing which expanded the set of MIME types we would
  consider signifying "unknown content" to include many (if not all) of
  the MIME types we would normally expect to be used in user-data
  multipart archives[0].

  This means that every part is now assigned its MIME type based on the
  first line of its content; the declared MIME types are ignored.

  In the specific reported case, a "text/cloud-boothook" part started
  with #!, which is appropriate and correct, but was therefore detected
  as "text/x-shellscript" due to this bug.

  [0] Specifically, it was expanded to include all the values in the
  dict at https://github.com/canonical/cloud-
  init/blob/master/cloudinit/handlers/__init__.py#L43-L54

  [Original Report]

  In the upstream Kubernetes project Cluster API, specifically the
  Cluster API AWS Provider, it will download a file securely from AWS
  Secrets Manager in the cloud-init script, save that file to a well
  known location, and then restart the cloud-init service through
  systemd.  After the cloud-init script is restarted, it will resolve
  the secrets file (that had previously not been there) and execute its
  commands.

  This worked fine on versions of cloud-init up until
  19.4-33-gbb4131a2-0ubuntu1~18.04.1.  Once upgrading to
  20.2-45-g5f7825e2-0ubuntu1~18.04.1 the secrets file is never resolved
  again.

  Some other information:

  - cloud-init is definitely successfully running twice based on systemd and cloud-init-output.
  - The /var/lib/cloud/instance/user-data.txt does show the reference to the well-known file at /etc/secret-userdata.txt
  - The "resolved" version of user-data at /var/lib/cloud/instance/user-data.txt.i does not include the resolved file.  Deleting this file and then restarted cloud-init does not solve the problem, as the file resolves again without it.

  Is there another command that is now required if you plan on
  restarting cloud-init for another execution where files are now
  present that were previously not?

  1. Cloud Provider: AWS
  2. Upstream issue: https://github.com/kubernetes-sigs/cluster-api-provider-aws/issues/1839 Instructions to recreate can be found in that issue including 2 public AMIs.

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