BSDTimezone: distinguish UTC and Etc/UTC

[tmshn]

SUMMARY

Improved idempotency of the timezone module on BSD.

It used not to distinguish between UTC and Etc/UTC, because both represents a same timezone.
This doesn't matter on normal usage, but cause weird unwilling behavior on a specific configuration.

I fixed this to distinguish those timezones and not to determine the timezone depending on user's input, but just read only from environment

In addition to that, now the order of scanning /usr/share/zoneinfo when /etc/localtime is copied rather than symlined is deterministic, and always returns same value.

ISSUE TYPE

• Bugfix Pull Request

COMPONENT NAME

timezone module

ANSIBLE VERSION

ansible 2.7.0.dev0 (devel 63d993e07f) last updated 2018/06/08 17:39:54 (GMT +000)
  config file = None
  configured module search path = [u'/home/tmshn/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /home/tmshn/ansible/lib/ansible
  executable location = /home/tmshn/ansible/bin/ansible
  python version = 2.7.13 (default, Jul 13 2017, 01:17:52) [GCC 4.2.1 Compatible FreeBSD Clang 3.8.0 (tags/RELEASE_380/final 262564)]

ADDITIONAL INFORMATION

I wrote the original code in #36715.

At that time, I was thinking that we can regard two timezones as same if their content in /usr/share/zoneinfo/ are same, because wherever the file is coming, only the content of the /etc/localtime decides how a system works.

Under this thought, I implemented to determine the timezone depending on a user's input. If the specified timezone can be regarded same as current one, we no need to change anything, and actually we wouldn't.

However, this meddlesome mix-up brings somewhat weird behavior with such configuration:

- name: 1. Set timezone to Etc/UTC
  timezone:
    name: Etc/UTC
# => after:  {'name': 'Etc/UTC'}

- name: 2. Set timezone to UTC
  timezone:
    name: UTC
# => before: {'name': 'UTC'}
# => after:  {'name': 'UTC'}

- name: 3. Set timezone to Etc/UTC again
  timezone:
    name: Etc/UTC
# => before: {'name': 'Etc/UTC'}
# => after:  {'name': 'Etc/UTC'}

Even though you set the timezone to Etc/UTC on the first step, and it actually reports "after" timezone is Etc/UTC, you'll see the "before" timezone is reported as UTC rather than Etc/UTC on the next step. The "before" value doesn't match the "after" value of the previous step.

Now I know this is my bad on designing the logic.

The problem was originally addressed at #40739 (comment), by pointing out a failure of the integration test:

TASK [timezone : ensure timezone reported as changed in checkmode] *********************************************************************************************************************************************
fatal: [testhost]: FAILED! => {
    "assertion": "timezone_set_checkmode.diff.before.name == 'Etc/UTC'",
    "changed": false,
    "evaluated_to": false
}

#40855 tried to fix this by modifying "strategy 2". However, it works only on an environment where /usr/share/zoneinfo/Etc/UTC is symlinked from /usr/share/zoneinfo/UTC

In the environment I tested, those files are physically separated and thus sudo ansible-test integration --allow-destructive timezone -v failed with the above error.

Now, with the patch of this pr, all clear.
I also added some test cases to make things clear.

[ansibot]

cc @indrajitr @jasperla
click here for bot help

[tmshn]

Adding tests reveals same problem exists in non-systemd linux... maybe I'll fix this in another pr.
That is due to a bug of dpkg-reconfigure, it rewrites /etc/timezone.

Maybe #34390 has something to do with the problem?

The problem looks hard to fix, so I decided to skip the new tests on non-systemd managed debian/ubuntu.

[ansibot]

The test ansible-test sanity --test import --python 2.6 [explain] failed with 1 error:

lib/ansible/modules/system/timezone.py:79:0: ImportError: cannot import name OrderedDict

click here for bot help

[tmshn]

ready_for_review

[tmshn]

cc @maxamillion

[maxamillion]

rebuild_merge