Traceback when passing user-data on GCE

The following reproduces (but produces an instance which I can't SSH in to; I had to capture the boot disk to discover this):

```
$ cat << EOF > cfg
bootcmd:
 - touch /tmp/cloud-init-works
EOF
gcloud compute instances create aa-$(date +%y%m%d-%H%M) --image daily-ubuntu-alan-1710-artful-v20170915a --image-project ubuntu-os-cloud-devel --metadata-from-file user-data=cfg
```

Can we get the full cloud-init log and possible a tar of /var/lib/cloud?

I upgraded an artful lxd container and ran the cloud-config you have via single
which is working fine. The stack-trace looks like it may be related to how
the user-data is passed in (as a mime-parthandler); so getting the metadata
in the obj.pkl file of the instance may help understand what's going on.

% lxc exec a1-test /bin/bash
root@a1-test:~# cat /etc/issue
Ubuntu Artful Aardvark (development branch) \n \l

root@a1-test:~# apt-cache policy cloud-init
cloud-init:
  Installed: 0.7.9-280-ge626966e-0ubuntu1
  Candidate: 0.7.9-280-ge626966e-0ubuntu1
  Version table:
 *** 0.7.9-280-ge626966e-0ubuntu1 500
        500 http://archive.ubuntu.com/ubuntu artful/main amd64 Packages
        100 /var/lib/dpkg/status
root@a1-test:~# cat test.yaml
#cloud-config
bootcmd:
 - touch /tmp/cloud-init-works

root@a1-test:~# cloud-init --force --file=test.yaml single --name cc_bootcmd --frequency=always
Cloud-init v. 0.7.9 running 'single' at Fri, 15 Sep 2017 22:10:19 +0000. Up 317.0 seconds.
root@a1-test:~# tail -n 15 /var/log/cloud-init.log
2017-09-15 22:07:08,762 - helpers.py[DEBUG]: Running config-cc_bootcmd using lock (<cloudinit.helpers.DummyLock object at 0x7f0671aaccc0>)
2017-09-15 22:07:08,773 - util.py[DEBUG]: Shellified 1 commands.
2017-09-15 22:07:08,773 - util.py[DEBUG]: Running command ['/bin/sh', '/run/cloud-init/tmp/tmpflh3erx2.sh'] with allowed return codes [0] (shell=False, capture=False)
2017-09-15 22:07:08,776 - util.py[DEBUG]: Reading from /proc/uptime (quiet=False)
2017-09-15 22:07:08,777 - util.py[DEBUG]: Read 12 bytes from /proc/uptime
2017-09-15 22:07:08,777 - util.py[DEBUG]: cloud-init mode 'single' took 0.084 seconds (0.00)
2017-09-15 22:10:20,010 - util.py[DEBUG]: Cloud-init v. 0.7.9 running 'single' at Fri, 15 Sep 2017 22:10:19 +0000. Up 317.0 seconds.
2017-09-15 22:10:20,012 - stages.py[DEBUG]: Using distro class <class 'cloudinit.distros.ubuntu.Distro'>
2017-09-15 22:10:20,013 - stages.py[DEBUG]: Running module cc_bootcmd (<module 'cloudinit.config.cc_bootcmd' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_bootcmd.py'>) with frequency always
2017-09-15 22:10:20,013 - helpers.py[DEBUG]: Running config-cc_bootcmd using lock (<cloudinit.helpers.DummyLock object at 0x7fcbc5c84cc0>)
2017-09-15 22:10:20,021 - util.py[DEBUG]: Shellified 1 commands.
2017-09-15 22:10:20,021 - util.py[DEBUG]: Running command ['/bin/sh', '/run/cloud-init/tmp/tmpht30mpak.sh'] with allowed return codes [0] (shell=False, capture=False)
2017-09-15 22:10:20,024 - util.py[DEBUG]: Reading from /proc/uptime (quiet=False)
2017-09-15 22:10:20,025 - util.py[DEBUG]: Read 12 bytes from /proc/uptime
2017-09-15 22:10:20,025 - util.py[DEBUG]: cloud-init mode 'single' took 0.079 seconds (1.00)
root@a1-test:~#
root@a1-test:~# ls -al /tmp/cloud-init-works
-rw-r--r-- 1 root root 0 Sep 15 22:10 /tmp/cloud-init-works

Dan,
your example config is not valid for 2 reasons
 a.) Touching a file in /tmp during boot is prone to give you issues as seen in bug 1707222.
 b.) if you want it consumed as cloud-config, it must start with '#cloud-config'.

I have reproduced this easily enough though.

I launched a xenial instance, and then added the cloud-init daily ppa , rm -Rf /var/lib/cloud && reboot will show it.

Ah, yeah, I mis-copied in my reproduced, but I was using cloud config with #cloud-config when actually running this.

This bug was fixed in the package cloud-init - 0.7.9-281-g10f067d8-0ubuntu1

---------------
cloud-init (0.7.9-281-g10f067d8-0ubuntu1) artful; urgency=medium

  * New upstream snapshot.
    - GCE: Fix usage of user-data. (LP: #1717598)

 -- Scott Moser <email address hidden> Mon, 18 Sep 2017 17:03:22 -0400