Traceback when passing user-data on GCE

Bug #1717598 reported by Dan Watkins on 2017-09-15
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cloud-init (Ubuntu)
Scott Moser

Bug Description

With the following cloud-config:

 - touch /tmp/cloud-init-works

I see the following traceback in the cloud-init log when I launch a GCE artful instance:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/cloudinit/cmd/", line 381, in main_init
  File "/usr/lib/python3/dist-packages/cloudinit/", line 54, in run
    return, functor, args, freq, clear_on_fail)
  File "/usr/lib/python3/dist-packages/cloudinit/", line 187, in run
    results = functor(*args)
  File "/usr/lib/python3/dist-packages/cloudinit/", line 538, in consume_data
  File "/usr/lib/python3/dist-packages/cloudinit/", line 612, in _consume_userdata
    self._do_handlers(user_data_msg, c_handlers_list, frequency)
  File "/usr/lib/python3/dist-packages/cloudinit/", line 528, in _do_handlers
  File "/usr/lib/python3/dist-packages/cloudinit/", line 511, in walk_handlers
    handlers.walk(data_msg, handlers.walker_callback, data=part_data)
  File "/usr/lib/python3/dist-packages/cloudinit/handlers/", line 220, in walk
    for part in msg.walk():
AttributeError: 'bytes' object has no attribute 'walk'

Related branches

Dan Watkins (daniel-thewatkins) wrote :

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
 - touch /tmp/cloud-init-works
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

Ryan Harper (raharper) wrote :

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
  Installed: 0.7.9-280-ge626966e-0ubuntu1
  Candidate: 0.7.9-280-ge626966e-0ubuntu1
  Version table:
 *** 0.7.9-280-ge626966e-0ubuntu1 500
        500 artful/main amd64 Packages
        100 /var/lib/dpkg/status
root@a1-test:~# cat test.yaml
 - 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 -[DEBUG]: Running config-cc_bootcmd using lock (<cloudinit.helpers.DummyLock object at 0x7f0671aaccc0>)
2017-09-15 22:07:08,773 -[DEBUG]: Shellified 1 commands.
2017-09-15 22:07:08,773 -[DEBUG]: Running command ['/bin/sh', '/run/cloud-init/tmp/'] with allowed return codes [0] (shell=False, capture=False)
2017-09-15 22:07:08,776 -[DEBUG]: Reading from /proc/uptime (quiet=False)
2017-09-15 22:07:08,777 -[DEBUG]: Read 12 bytes from /proc/uptime
2017-09-15 22:07:08,777 -[DEBUG]: cloud-init mode 'single' took 0.084 seconds (0.00)
2017-09-15 22:10:20,010 -[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 -[DEBUG]: Using distro class <class 'cloudinit.distros.ubuntu.Distro'>
2017-09-15 22:10:20,013 -[DEBUG]: Running module cc_bootcmd (<module 'cloudinit.config.cc_bootcmd' from '/usr/lib/python3/dist-packages/cloudinit/config/'>) with frequency always
2017-09-15 22:10:20,013 -[DEBUG]: Running config-cc_bootcmd using lock (<cloudinit.helpers.DummyLock object at 0x7fcbc5c84cc0>)
2017-09-15 22:10:20,021 -[DEBUG]: Shellified 1 commands.
2017-09-15 22:10:20,021 -[DEBUG]: Running command ['/bin/sh', '/run/cloud-init/tmp/'] with allowed return codes [0] (shell=False, capture=False)
2017-09-15 22:10:20,024 -[DEBUG]: Reading from /proc/uptime (quiet=False)
2017-09-15 22:10:20,025 -[DEBUG]: Read 12 bytes from /proc/uptime
2017-09-15 22:10:20,025 -[DEBUG]: cloud-init mode 'single' took 0.079 seconds (1.00)
root@a1-test:~# ls -al /tmp/cloud-init-works
-rw-r--r-- 1 root root 0 Sep 15 22:10 /tmp/cloud-init-works

Changed in cloud-init (Ubuntu):
importance: Undecided → High
status: New → Incomplete
Scott Moser (smoser) wrote :

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'.

Scott Moser (smoser) wrote :

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.

Changed in cloud-init (Ubuntu):
status: Incomplete → Confirmed
assignee: nobody → Scott Moser (smoser)
status: Confirmed → In Progress
Dan Watkins (daniel-thewatkins) wrote :

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

Launchpad Janitor (janitor) wrote :

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

Changed in cloud-init (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers