plumb timezone into VM/container |
||||||
Issue descriptionThe VM and container should have the same timezone as the host, instead of UTC.
,
May 9 2018
,
May 11 2018
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 ?
,
Jun 29 2018
Issue 859105 has been merged into this issue.
,
Jun 29 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/docs/+/dbfb28e50d32fcf7a39d6c17831d8786f15d0ef5 commit dbfb28e50d32fcf7a39d6c17831d8786f15d0ef5 Author: Mike Frysinger <vapier@chromium.org> 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 <vapier@chromium.org> Tested-by: Mike Frysinger <vapier@chromium.org> Reviewed-by: Stephen Barber <smbarber@chromium.org> [modify] https://crrev.com/dbfb28e50d32fcf7a39d6c17831d8786f15d0ef5/containers_and_vms.md
,
Sep 17
Issue 852638 has been merged into this issue.
,
Oct 10
,
Oct 10
,
Oct 10
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.
,
Oct 10
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.
,
Oct 29
Chirantan suggested plumbing a message to termplin and using LXD's timezone setting funcationality from there.
,
Oct 29
Yes, I think we just have to do the websocket equivalent of
lxc config set <container> environment.TZ <timezone>
,
Nov 9
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.
,
Nov 9
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 ?
,
Nov 9
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.
,
Nov 10
> 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
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
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.
,
Dec 3
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/94572fa0902014ce968fb3e470df8538fed25dd7 commit 94572fa0902014ce968fb3e470df8538fed25dd7 Author: Fletcher Woodruff <fletcherw@chromium.org> Date: Mon Dec 03 20:43:36 2018 vm_tools: Add parser for TZif files to cicerone In order to set timezones within containers in a portable way, we need support for extracting POSIX compliant timezone strings from the timezones located in /usr/share/zoneinfo. Adds a simple parser for TZif version 2 and version 3 formats that extracts the embedded timezone string. It does not support version 1 formats because those do not have the embedded string and are not generated by newer versions of the timezone-data package. BUG=chromium:829934 TEST=run unit tests Change-Id: I7e149c070de46827a2e6a2bce9d88cb59932116d Reviewed-on: https://chromium-review.googlesource.com/1342659 Commit-Ready: Fletcher Woodruff <fletcherw@chromium.org> Tested-by: Fletcher Woodruff <fletcherw@chromium.org> Reviewed-by: Chirantan Ekbote <chirantan@chromium.org> Reviewed-by: Mike Frysinger <vapier@chromium.org> [modify] https://crrev.com/94572fa0902014ce968fb3e470df8538fed25dd7/vm_tools/host.gypi [add] https://crrev.com/94572fa0902014ce968fb3e470df8538fed25dd7/vm_tools/cicerone/EST_test.tzif [add] https://crrev.com/94572fa0902014ce968fb3e470df8538fed25dd7/vm_tools/cicerone/tzif_parser.cc [add] https://crrev.com/94572fa0902014ce968fb3e470df8538fed25dd7/vm_tools/cicerone/tzif_parser_test.cc [add] https://crrev.com/94572fa0902014ce968fb3e470df8538fed25dd7/vm_tools/cicerone/Indian_Christmas_test.tzif [add] https://crrev.com/94572fa0902014ce968fb3e470df8538fed25dd7/vm_tools/cicerone/tzif_parser.h [add] https://crrev.com/94572fa0902014ce968fb3e470df8538fed25dd7/vm_tools/cicerone/Pacific_Fiji_test.tzif
,
Dec 12
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform/tremplin/+/08be0bfa0b08da78912ecc3c495d56da6ef419a5 commit 08be0bfa0b08da78912ecc3c495d56da6ef419a5 Author: Fletcher Woodruff <fletcherw@chromium.org> Date: Wed Dec 12 00:19:32 2018 tremplin: Add SetTimezone function Adds SetTimezone function to tremplin interface which attempts to set timezone through systemd for all containers, falling back to the POSIX standard for the TZ environment variable if timedatectl fails. BUG=chromium:829934 TEST=Same as dependent CL (run SetTimezone and check that 'date' returns proper timezone) CQ-DEPEND=CL:1323758 Change-Id: Id08e6d0508ddbcd92bdbe836cc55e5dc48ac9291 Reviewed-on: https://chromium-review.googlesource.com/1323475 Commit-Ready: Fletcher Woodruff <fletcherw@chromium.org> Tested-by: Fletcher Woodruff <fletcherw@chromium.org> Reviewed-by: Stephen Barber <smbarber@chromium.org> [modify] https://crrev.com/08be0bfa0b08da78912ecc3c495d56da6ef419a5/src/chromiumos/tremplin/tremplin.go
,
Dec 12
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/6d3a88fb484a69a1af3019d331312566a59e590e commit 6d3a88fb484a69a1af3019d331312566a59e590e Author: Fletcher Woodruff <fletcherw@chromium.org> Date: Wed Dec 12 00:19:33 2018 vm_tools: Add SetTimezone to cicerone_client Adds command to cicerone_client that sets the timezone for all LXC containers in all VMs. Timezones are specified using names from the timezone-data package. Example names are 'Etc/UTC', 'America/Denver', 'Africa/Accra', etc. If the guest VM does not support these names, a fallback POSIX standard format for the TZ environment variable is used. Any failure messages from a particular container are aggregated and reported by cicerone_client. BUG=chromium:829934 TEST=Spin up multiple VMs each with container, check that 'lxc exec [container] date' from vsh returns UTC time. Run cicerone_client --set_timezone, check that 'lxc exec [container] date' returns expected timezone in all containers. CQ-DEPEND=CL:1323475 CQ-DEPEND=CL:1342659 Change-Id: I7a9d97b49537bfd0724895bb5d73eaf17fb188e6 Reviewed-on: https://chromium-review.googlesource.com/1323758 Commit-Ready: Fletcher Woodruff <fletcherw@chromium.org> Tested-by: Fletcher Woodruff <fletcherw@chromium.org> Reviewed-by: Chirantan Ekbote <chirantan@chromium.org> Reviewed-by: Mike Frysinger <vapier@chromium.org> [modify] https://crrev.com/6d3a88fb484a69a1af3019d331312566a59e590e/vm_tools/proto/tremplin.proto [modify] https://crrev.com/6d3a88fb484a69a1af3019d331312566a59e590e/system_api/dbus/vm_cicerone/cicerone_service.proto [modify] https://crrev.com/6d3a88fb484a69a1af3019d331312566a59e590e/vm_tools/cicerone/client.cc [modify] https://crrev.com/6d3a88fb484a69a1af3019d331312566a59e590e/vm_tools/cicerone/service.cc [modify] https://crrev.com/6d3a88fb484a69a1af3019d331312566a59e590e/vm_tools/cicerone/service.h [modify] https://crrev.com/6d3a88fb484a69a1af3019d331312566a59e590e/vm_tools/cicerone/virtual_machine.h [modify] https://crrev.com/6d3a88fb484a69a1af3019d331312566a59e590e/system_api/dbus/vm_cicerone/dbus-constants.h [modify] https://crrev.com/6d3a88fb484a69a1af3019d331312566a59e590e/vm_tools/cicerone/virtual_machine.cc |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by chirantan@chromium.org
, Apr 6 2018