This bug was fixed in the package cloud-init - 0.7.5-0ubuntu1.11
---------------
cloud-init (0.7.5-0ubuntu1.11) trusty; urgency=medium
[ Felipe Reyes ]
* d/patches/fix-consumption-of-vendor-data.patch:
- Fix consumption of vendor-data in OpenStack to allow namespacing
(LP: #1469260).
[ Scott Moser ]
* d/patches/lp-1461242-generate-ed25519-host-keys.patch:
- ssh: generate ed25519 host keys if supported (LP: #1461242)
-- Scott Moser <smo...@ubuntu.com> Fri, 11 Sep 2015 20:22:00 -0400
** Changed in: cloud-init (Ubuntu Trusty)
Status: Fix Committed => 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/1469260
Title:
[SRU] Custom vendor data causes cloud-init failure on 0.7.5
Status in cloud-init:
Fix Released
Status in cloud-init package in Ubuntu:
Fix Released
Status in cloud-init source package in Trusty:
Fix Released
Status in cloud-init source package in Utopic:
Invalid
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://code.launchpad.net/~ost-maintainers/openstack-charm-testing/trunk and
run: juju deployer -c default.yaml -d -v -s 10 trusty-kilo
* configure vendor data
- Edit /etc/nova/nova.conf in neutron-gateway unit(s), include the
following two lines:
vendordata_driver=nova.api.metadata.vendordata_json.JsonFileVendorData
vendordata_jsonfile_path=/etc/nova/vendordata.json
- Create /etc/nova/vendordata.json in neutron-gateway unit(s) with the
following content:
{"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": "4996e2b67d2941818646481453de1efe", "users":
[{"username": "erhudy", "sshPublicKeys": [], "uuid": "erhudy"}],
"name": "TestTenant"}
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/cloud/instance/obj.pkl - wb: [256] 9751 bytes
2015-06-25 21:41:02,178 - util.py[DEBUG]: Writing to
/var/lib/cloud/instances/65c9fb0c-0700-4f87-a22f-c59534e98dfb/user-data.txt -
wb: [384] 0 bytes
2015-06-25 21:41:02,184 - util.py[DEBUG]: Writing to
/var/lib/cloud/instances/65c9fb0c-0700-4f87-a22f-c59534e98dfb/user-data.txt.i -
wb: [384] 345 bytes
2015-06-25 21:41:02,185 - util.py[DEBUG]: Writing to
/var/lib/cloud/instances/65c9fb0c-0700-4f87-a22f-c59534e98dfb/vendor-data.txt -
wb: [384] 234 bytes
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_string(raw_data, headers=None):
if not raw_data:
raw_data = ''
if not headers:
headers = {}
data = util.decomp_gzip(raw_data)
if "mime-version:" in data[0:4096].lower():
msg = email.message_from_string(data)
for (key, val) in headers.iteritems():
_replace_header(msg, key, val)
else:
mtype = headers.get(CONTENT_TYPE, NOT_MULTIPART_TYPE)
maintype, subtype = mtype.split("/", 1)
msg = MIMEBase(maintype, subtype, *headers)
msg.set_payload(data)
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_binary(), which
appears to always return a string.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1469260/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
