plumb timezone into VM/container
Project Member Reported by smbar...@chromium.org, Apr 6 2018
The VM and container should have the same timezone as the host, instead of UTC.
Apr 6 2018,
I had a CL to do this a while back: https://chromium-review.googlesource.com/c/chromiumos/platform2/+/575520 We abandoned it at the time because timezones are hard and we didn't really know how we were going to use that information but maybe now things have settled down enough that we can revisit that decision.
i think all the issues i raised in that CL still apply :). i'm not saying we have to abandon everyone because supporting 100% is neigh impossible, but we do have to come up with a documented/flexible design as to what we do support. it'd probably look something like: - figure out our current timezone via its tzdata-name if possible - pass the name, the UTC offset, and the tzdata data file content to maitred - detect if the container uses systemd, if so, try running `timedatectl set-timezone <name>` - if that fails - write out the tzdata content to /etc/localtime in the container - see if /usr/share/zoneinfo/$tzdataname exists, and if so, write the name to /etc/timezone - if it doesn't exist, try writing the simple UTC offset info to /etc/timezone does docker/etc... have a standard method for propagating timezone details into their containers ?
Issue 859105 has been merged into this issue.
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/docs/+/dbfb28e50d32fcf7a39d6c17831d8786f15d0ef5 commit dbfb28e50d32fcf7a39d6c17831d8786f15d0ef5 Author: Mike Frysinger <email@example.com> Date: Fri Jun 29 22:29:19 2018 containers_and_vms: add a FAQ about timezones BUG=chromium:829934 Change-Id: I91cdfee4cc13b3fc9fcacf290d5aa421c70d7378 Reviewed-on: https://chromium-review.googlesource.com/1121136 Commit-Ready: Mike Frysinger <firstname.lastname@example.org> Tested-by: Mike Frysinger <email@example.com> Reviewed-by: Stephen Barber <firstname.lastname@example.org> [modify] https://crrev.com/dbfb28e50d32fcf7a39d6c17831d8786f15d0ef5/containers_and_vms.md
Issue 852638 has been merged into this issue.
Issue 823406 has been merged into this issue.
I'll take this over. Merging this with issue 823406 as the work to do both will be quite similar. Current plan: Modify concierge and maitre'd to communicate both time zone and current time from host to guest. It'll send the time once an hour and on resume from sleep. It'll send time zone on VM startup and (hopefully) when it changes, assuming we can get notified on time zone changes in the host.
Putting this back to Chirantan; it seems the timezone issue and time drift issue are different enough that it doesn't make sense to track them in the same bug.
Chirantan suggested plumbing a message to termplin and using LXD's timezone setting funcationality from there.
Yes, I think we just have to do the websocket equivalent of lxc config set <container> environment.TZ <timezone>
Setting the TZ variable is a POSIX standard, but using tzdata names (America/Denver, e.g.) is non-standard. There is a less-readable but POSIX standard format that we can use (https://www.ibm.com/developerworks/aix/library/au-aix-posix/index.html) if we parse out that data from the tzdata file.
TZ is documented here: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03 i agree that it's not exactly the most readable. but it should be portable, and we don't have to worry about the container's tzdata being up to date since we'll have a single source of truth (the browser). tzdata adds/removes names over time, and rules change (as countries change their laws). my focus is: - the API over the VM boundary should be done using UTC & offsets - names are fragile, and break down not only across UNIX implementations, but def across other OS's (Windows/macOS/etc...) which is why i've been strongly discouraging that at the VM boundary - once inside the VM, the service can dynamically decide what's best (i bounced some ideas in comment #3) - if you want to implement it with `lxc config set ... environment.TZ <POSIX form>` that's fine i'm assuming the lxc env setting will propagate into the container ... somehow. does it just set it on the env of the main init process ? so if the TZ changes, you need to reboot the container to pick up the changes ?
Your point about communicating across the VM boundary with the UTC offset and DST switching dates (which are not consistent globally :/) makes sense, but we also lose historical time data that is encoded in tzfiles. Couldn't we potentially report incorrect times in the container if somebody tried to look at historical times? I realize this is a bit of an edge case but I still want to acknowledge it. What is wrong with sending the host machine's tzdata file into the VM and installing it into /usr/share/zoneinfo? If we have the proper file and we symlink to it from /etc/localtime, does that work. Would we need to install that file into all containers (since my understanding is the lxc containers maintain a separate filesystem?) Re. propagating the changes, when the environment var changed, I saw the container pick it up immediately. I'm not sure how that works though. It might have been because I was using 'lxc exec [container] date', and running that somehow pulls from the TZ variable.
> Couldn't we potentially report incorrect times in the container if somebody tried to look at historical times you're certainly correct that this would happen for times that get localized (vs showing in the original utc or originating TZ). > What is wrong with sending the host machine's tzdata file into the VM this is a bit of a loaded question because of the unstated assumptions ;). the tzdata binary format is not guaranteed to be backwards compatible, nor is the format specified by any standard. breaking changes are rare, but have happened. whether the file can be understood directly also depends entirely on the software. glibc natively parses it, but there's no guarantee that the inside of the VM or inside of the container is glibc, or a compatible version. that's why I think the API across the VM boundary needs to be independent/marshalled ourselves, and then leave it to the logic inside the VM to make decisions about the best way to use that data. if we look at the timezone-data package and how it structures its rules in source form, I think it should be "easy" to define a protobuf API that encompasses it for all our practical needs: a list of start/stop date/time stamps and the UTC offset for that timespan. then the daemon inside the VM can decide what to do next. for v1, rip off the latest rule (perhaps for v1 we only send over one entry -- the current one) and stuff that into the TZ var. that should get us going for the short/mid term. for something more complete, we can have the code in the VM generate a compatible tzdata binary and write it to /etc/localtime. if the container isn't compatible, it can deal with converting that file to something it can handle. if the code inside the VM isn't Linux, then it still has the full timezone info necessary to convert into whatever form makes sense for the runtime. > Re. propagating the changes ... I expect that is entirely because you kept going through lxc which updated the immediate env everytime. a better test would be to ssh in or run Terminal, do the env set in another session, and then check behavior in the preexisting ssh/terminal sessions. I expect `date` wouldn't update, but I'd be interested in seeing if systemd/journald picked it up right away, or if a new ssh session picked it up.
Nov 12 (4 days ago),
Re #16 I tested propagating the changes again: I started a shell in the container and then changed the date from another terminal. Immediately, neither timedatectl, journalctl, nor date reflected the change. After restarting the shell, both date and journalctl reflected the new timezone, but timedatectl did not. A further restart of the container did not change timedatectl's output. Is there a parser for tzdata files available? Maybe it's best for me to write my own, and if the format changes in a later version of timezone-data then we can fix it?
Nov 13 (4 days ago),
since we use the timezone-data package directly, should refer to that: https://github.com/eggert/tz the project is in the public-domain, and tzfile.8 and tzfile.h files should help parse the binary files. there might be existing "TZiF" parsers out there, but i suspect it'll be easier if we just implemented it ourselves.
Sign in to add a comment