[SRU] Custom vendor data causes cloud-init failure on 0.7.5
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Fix Released
|
Medium
|
Unassigned | ||
cloud-init (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Trusty |
Fix Released
|
Medium
|
Felipe Reyes | ||
Utopic |
Invalid
|
Medium
|
Unassigned |
Bug Description
[Impact]
When a vendor data json provides a dictionary without a 'cloud-init' key, cloud-init renders a non functional user-data, so any configuration (i.e. ssh public keys to use) is missed.
This prevents cloud providers from publishing a vendor data that is not intended to be consumed by cloud-init.
This patch checks for the existence of 'cloud-init' key and tries to get None, a string or a list as value, if this process fails or cloud-init key is missing the vendor data is set to None.
[Test Case]
* deploy an OpenStack cloud (easy right? :) )
- the easiest way is to branch https:/
* configure vendor data
- Edit /etc/nova/nova.conf in neutron-gateway unit(s), include the following two lines:
vendordata_
vendordata_
- Create /etc/nova/
{"custom": {"a": 1, "b": [2, 3]}}
- Restart nova-api-metadata (sudo service nova-api-metadata restart)
* Launch an instance using trusty
Expected result:
- the new instance is launched and is accesible according to the configuration used
Actual result:
- cloud-init fails to configure the ssh public key
[Regression Potential]
* This patch is already part of Vivid and there are no known issues.
* This proposed fix was tested with a custom image and no issues were detected.
[Other Info]
I encountered this issue when adding custom vendor data via nova-compute. Originally the bug manifested as SSH host key generation failing to fire when vendor data was present (example vendor data below).
{"msg": "", "uuid": "4996e2b67d2941
I launched a volume-backed instance, waited for it to fail, then terminated it and mounted its root volume to examine the logs. What I found was that cloud-init was failing to process vendor-data into MIME multipart (note the absence of the line that indicates that cloud-init is writing vendor-data.txt.i):
2015-06-25 21:41:02,178 - util.py[DEBUG]: Writing to /var/lib/
2015-06-25 21:41:02,178 - util.py[DEBUG]: Writing to /var/lib/
2015-06-25 21:41:02,184 - util.py[DEBUG]: Writing to /var/lib/
2015-06-25 21:41:02,185 - util.py[DEBUG]: Writing to /var/lib/
2015-06-25 21:41:02,185 - util.py[DEBUG]: Reading from /proc/uptime (quiet=False)
After following the call chain all the way down, I found the problematic code in user_data.py:
# Coverts a raw string into a mime message
def convert_
if not raw_data:
raw_data = ''
if not headers:
headers = {}
data = util.decomp_
if "mime-version:" in data[0:
msg = email.message_
for (key, val) in headers.
else:
mtype = headers.
maintype, subtype = mtype.split("/", 1)
msg = MIMEBase(maintype, subtype, *headers)
return msg
raw_data in the case that is failing is a dictionary rather than the expected string, so slicing into data causes a TypeError: unhashable type exception.
I think this bug was fixed after a fashion in 0.7.7, where the call to util.decomp_gzip() is now wrapped by util.decode_
Related branches
Changed in cloud-init (Ubuntu Trusty): | |
assignee: | nobody → Felipe Reyes (freyes) |
description: | updated |
summary: |
- Custom vendor data causes cloud-init failure on 0.7.5 + [SRU] Custom vendor data causes cloud-init failure on 0.7.5 |
Changed in cloud-init (Ubuntu Trusty): | |
status: | New → In Progress |
marking trunk fix-released and ubuntu fixed-released per bug openers suggestion that it was fixed in 0.7.7 . I have not reproduced though.