In 22.2 cloud-init fails when phone-home module does not have "tries" parameter
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Fix Released
|
High
|
James Falcon | ||
cloud-init (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Undecided
|
Unassigned | ||
Impish |
Fix Released
|
Undecided
|
Unassigned | ||
Jammy |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
=== Begin SRU Template ===
[Impact]
The cloud-init "phone home" module contains an optional "tries" parameter. In release 22.2, this was accidentally changed to become mandatory. Any previously working cloud-config that didn't contain the "tries" parameter will now cause the module exit with exception. This happened because an overly broad exception handler for converting the 'tries' string to an int was changed to only raise on ValueError. However, if None (or any other non-string) is passed, a TypeError is raised, and this needs to be caught as well.
[Test Case]
1. Launch an Ubuntu instance on any cloud-init supported platform with the following userdata:
#cloud-config
phone_home:
url: http://
post: all
2. By inspecting /var/log/
url_helper.
[Regression Potential]
The parsing exceptions being caught should now be broad enough to handle any configuration we receive, but if not, we would still exit the module with exception.
[Other Info]
Github PR: https:/
=== End SRU Template ===
Initial bug:
Hi!
We have some user-data files where we use the phone-home module of cloud-init.
So far we did not use it's "tries" parameter and everything worked.
However now in version 22.2 there was a change which causes cloud-init to fail.
https:/
In our case this change in the exception handling throws a TypeError, instead of the ValueError that is excepted:
File "/usr/lib/
tries = int(tries) # type: ignore
TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType'
While we can add the "tries" parameter (and after that everything works just like before),
this exception should be handled properly.
Also according to guidelines:
1. Tell us your cloud provider
None
2. Any appropriate cloud-init configuration you can provide us
phone-home module
3. Perform the following on the system and attach it to this bug:
no logs are necessary
Best regards:
Zsolt
description: | updated |
Changed in cloud-init: | |
status: | New → Triaged |
importance: | Undecided → High |
description: | updated |
tags: |
added: verification-done verification-done-bionic verification-done-focal verification-done-impish verification-done-jammy removed: verification-needed verification-needed-bionic verification-needed-focal verification-needed-impish verification-needed-jammy |
Changed in cloud-init (Ubuntu): | |
status: | In Progress → Fix Committed |
We ran into the exact same issue.
All our VM creations suddenly starts failing yesterday, which was a bit surprising because that's why we were using LTS in the first place ;)
Adding the "tries" parameter to phone_home fixed the issue immediately.