[ Impact ]
In very early boot, before cloud-init creates /run/cloud-init/status.json calls to cloud-init status --wait can result in a Traceback due to the the default JSON value of "datasource": null. This fix handles gracefully reporting datasource=None instead of assuming that we will have a non-empty string for the detected datasource type.
[ Test Plan ]
The following test plan reprouced this issue 100% of the time on LXC containers with images containing cloud-init version 22.4.0
* Create a clean LXC image from <series>-proposed pocket
* Launch and lxc container and immediately run cloud-init status --wait to ensure no race exists.
cat > setup_proposed.sh <<EOF
#/bin/bash
mirror=http://archive.ubuntu.com/ubuntu
echo deb \$mirror \$(lsb_release -sc)-proposed main | tee /etc/apt/sources.list.d/proposed.list
apt-get update -q
apt-get install -qy cloud-init
EOF
for RELEASE in bionic focal jammy kinetic; do
echo "### test SRU for $RELEASE"
lxc launch ubuntu-daily:$RELEASE sru-$RELEASE;
lxc exec sru-$RELEASE -- cloud-init status --wait;
echo "### update to -proposed pocket"
lxc file push setup_proposed.sh sru-$RELEASE/
lxc exec sru-$RELEASE -- /sru-$RELEASE/setup_proposed.sh
echo "### boot clean and validate cloud-init status --wait
lxc exec sru-$RELEASE -- cloud-init clean --logs --reboot
lxc exec sru-$RELEASE -- cloud-init status --wait
lxc exec sru-$RELEASE -- grep Traceback /var/log/cloud-init.log
done
[ Where problems could occur ]
* The fix shores up a gap in the initial/default state of /run/cloud-init/status.json before datasource is initially detected. It only touches logic if very early boot to supplement the value types supported for the 'datasource' key. This fix generally doesn't expose any change in behavior beyond handling the early boot race condition. If this risk were implemented incorrectly. Any subsequent calls to `cloud-init status` or `cloud-init status --wait` would traceback in a similar fashion. Since later invocations for cloud-init status are validated by existing cloud-init integration tests this risk is low.
[ Other Info ]
This regression discovery was during SRU validation timeframe for 22.4.0 and is subsequently been included in cloud-init upstream version 22.4.2. (Already published to Ubuntu Lunar (23.04).
[ Original Description ]
Hello,
Cloud-init version 2.4-0ubuntu4 (currently in lunar), fails in certain conditions when running cloud-init status --wait:
Traceback (most recent call last):
File "/usr/bin/cloud-init", line 33, in <module>
sys.exit(load_entry_point('cloud-init==22.4', 'console_scripts', 'cloud-init')())
File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 1086, in main
retval = util.log_time(
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2680, in log_time
ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/cmd/status.py", line 119, in handle_status_args
details = get_status_details(paths)
File "/usr/lib/python3/dist-packages/cloudinit/cmd/status.py", line 232, in get_status_details
datasource, _, _ = value.partition(" ")
AttributeError: 'NoneType' object has no attribute 'partition'
We noticed that it broke our subiquity pipeline, see https://github.com/canonical/subiquity/actions/runs/3493835896/jobs/5922374078
This seems to fail when invoking cloud-init status --wait (very) early.
Reproducer:
#!/bin/bash
lxc launch --ephemeral ubuntu-daily:lunar test
lxc exec test -- cloud-init status --wait
I believe it might also affect the versions being SRUed (https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1996645) but I don't have a good way to test it myself.
After doing a quick bisect, I think the regression was introduced in https:/