cc_timezone fails on Ubuntu Bionic and Xenial minimal

[Joshua Powers]

Summary
===
On Ubuntu Bionic and Xenial minimal images, there is no tzdata package. As a result, when cloud-init tries to set the timezone it will fail and produce a stack trace.

Expected Result
===
No trace and no failure of the cloud-config.service :)

Actual result
===
2020-07-20 18:13:22,515 - util.py[DEBUG]: Running module timezone (<module 'cloudinit.config.cc_timezone' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_timezone.py'>) failed
  File "/usr/lib/python3/dist-packages/cloudinit/config/cc_timezone.py", line 47, in handle
    cloud.distro.set_timezone(timezone)
  File "/usr/lib/python3/dist-packages/cloudinit/distros/debian.py", line 165, in set_timezone
    distros.set_etc_timezone(tz=tz, tz_file=self._find_tz_file(tz))
OSError: Invalid timezone America/Vancouver, no file found at /usr/share/zoneinfo/America/Vancouver

Steps to reproduce
===
$ wget https://cloud-images.ubuntu.com/daily/server/minimal/releases/bionic/release/ubuntu-18.04-minimal-cloudimg-amd64.img
$ multipass launch file:///$(pwd)/ubuntu-18.04-minimal-cloudimg-amd64.img --name=bionic-minimal
$ multipass exec bionic-minimal -- sudo systemctl list-units --failed --no-legend
# note that cloud-config.service fails
$ multipass exec bionic-minimal -- sudo cat /var/log/cloud-init.log | grep timezone

[Ryan Harper (raharper)]

What happens on Focal?

[Ryan Harper (raharper)]

https://cloud-images.ubuntu.com/daily/server/minimal/daily/focal/current/focal-minimal-cloudimg-amd64.manifest

Has tzdata ...

This looks like a cloudimg issue, not cloud-init.

https://cloud-images.ubuntu.com/daily/server/minimal/daily/bionic/current/bionic-minimal-cloudimg-amd64.manifest

[Ryan Harper (raharper)]

Let's get a comment w.r.t whether minimal images are required to support setting TIMEZONE;

It appears like they should since focal has tzdata; so I'd lean on not doing anything in cloud-init; it seems like a valid failure (you wanted to set a timezone, but we cannot without tzdata).

[Joshua Powers (powersj)]

Based on discussions with foundations, it is unintentional that it's been pulled in on focal. The reason it is in focal is due to libicu is pulling it in.

[Dan Watkins (oddbloke)]

OK, so this is not an issue with cloud-init or the minimal cloud images in their default configuration. The issue we're running into here is that multipass will include `timezone: <your tz>` in the user-data it passes to guests, but it does not include config to ensure that `tzdata` is installed. I've chatted to the multipass folks in IRC, and will be filing an issue with them shortly.

There is a broader question about cloud-init's behaviour: what should it do if it can't find the specified timezone definition? It seems to me there are two options: (a) treat this as a configuration error and fail, or (b) attempt to ensure that zone files are installed (by installing tzdata in the Ubuntu case) and retry timezone configuration.

I would lean towards (a) for a couple of reasons. Firstly, the only case we know of missing tzdata is on intentionally minimal images; if a user is choosing to use the stripped-down images then they probably want to be involved in the decisions about what software is installed on the system, and may be surprised by cloud-init silently installing a package. In a sense, we should let them be explicit in their decision on the trade-off between "setting a timezone" and "having as few packages as possible". Secondly, we cannot easily determine from within the image why the specified timezone is unavailable: is "no file found at /usr/share/zoneinfo/America/Chcagio" because we don't have timezone definitions installed, or because there is no such timezone?

Any thoughts from other folks?

[Dan Watkins (oddbloke)]

(https://github.com/canonical/multipass/issues/1665 is the multipass issue.)

[Paride Legovini (paride)]

I'd also prefer (a) for the reasons stated by Dan and for one more: we already have a way to declare dependencies/relationships between packages, and that's dpkg and the d/control file. If cloud-init depends on tzdata, then I think it should declare the dependency, and not try to "manually" install the package, a process that can go wrong or get stuck for a number of reasons (broken sources.list, missing media, stuck apt lock, ...).

[Dan Watkins (oddbloke)]

Marking this Incomplete so it'll age out if no-one makes a case against (a).

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3761