[semarie]

Following xapi-project/xen-api#7332, this commit changes the way the DHCP mode of NTP is implemented.

Instead of relying on executable permission of chrony.sh (dhclient hook), use the presence of sourcedir line in chrony.conf.

It makes the implementation to depend only on chrony instead of both chrony and dhclient.

Tracking-reference: XCPNG-1094

[semarie]

This PR should not be committed before xapi-project/xen-api#7332 .
Else xsconsole will report faulty NTP status.

[semarie]

Cc @changlei-li

[semarie]

Tests:

• run xsconsole with older xapi (faulty status)
• run xsconsole with new xapi (correct status: DHCP / Default / Manual / Disabled )
• use xsconsole to change the different modes (with network static and with network DHCP)

[semarie]

Last push:

• lighter UpdateNTP to update only the NTP part (as UpdateNTPFromConf before)
• remove unused stat import

[changlei-li]

The two disables are legacy behaviors. I think it need more consideration for the remove. What is chrony-wait and what is the impact.

[semarie]

Thanks for pointing this problem.

Let's first evacuate self.DisableService("chronyd") removal : it is safe to remove the line as chronyd service is already disabled by XAPI when ntp-mode is set to Disabled.

Regarding chrony-wait the situation is (a lot) more complex.

What chrony-wait is

• It is a separate systemd unit shipped by chrony package.
• It is not managed by XAPI.
• It is enabled by host-installer on (every NTP-enabled install)[https://github.com/xenserver/host-installer/blob/333a075c3f466f3a2ccc7d118acd0e8cb4b2631d/backend.py#L519).

It seems to be used to guarantees a synced clock before XAPI toolstack start: at boot, it blocks (up to 180 s) until chronyd has synced the clock (it is using waitsync chronyc command), gating time-sync.target, which in turn gates xapi.service / xapi-init-complete.target (both After=time-sync.target).

The chrony-wait unit has Requires=chronyd.service line.

XAPI state (without xsconsole involving) - setting ntp-mode=Disabled with XAPI

XAPI's set_ntp_mode('Disabled') only calls timedatectl set-ntp false (disable_ntp_service). timedated only manages the units listed in /usr/lib/systemd/ntp-units.d/*.list, which for chrony is only chronyd.service (chrony-wait is never in that list). So XAPI can disable/stop chronyd, but it has no way to touch chrony-wait.

After setting ntp-mode=Disabled with xe, at the next boot, chrony-wait (still enabled) is pulled into the transaction and, via Requires=chronyd.service, pulls chronyd back in and starts it. It is re-arming NTP (eventually overwriting the manually-set time if any source is present). If NTP sources was cleared, chrony-wait will run waitsync which can't complete, so the boot stalls up to 180 s on time-sync.target, delaying xapi.

So I think it is an issue in the XAPI host-ntp design, in the fact it doesn't manage chrony-wait unit.

The scenario would be:

1. fresh install with NTP enabled : chrony-wait is enabled
2. xe host-param-set uuid=<uuid> ntp-mode=Disabled : chronyd is disabled, but chrony-wait stays enabled
3. on next boot, chrony-wait starts, it pulls chronyd, waitsync can't complete so the boot stalls up to 180s. Additionally, at XAPI starts, ntp-mode is refreshed from system state and as chronyd is active, ntp-mode isn't Disabled anymore.

xsconsole state

In the current code, chrony-wait could be disabled (by setting time to manual, disabling NTP) but it could never been re-enabled.
When re-enabling NTP, xsconsole delegate it to XAPI (xsconsole SetNTPMode function). But XAPI never changes chrony-wait unit state.
It means that once you used xsconsole to disable NTP, XAPI isn't delayed anymore to start with synced clock.

What to do next

Open an issue in xen-api

Several cases are problematics:

• installation with NTP enabled (chrony-wait enabled): you can't properly disable NTP (chronyd daemon is still starting at boot, ntp-mode is resync at boot, delayed boot)
• installation without NTP enabled (chrony-wait disabled): if you enable NTP, xapi is started with unsync clock (chrony-wait is still disabled)

Decide what to do with chrony-wait unit

If we consider starting xapi without chrony-wait is fine :

• host-installer shouldn't enable it : something to change in the current code.
• xsconsole shouldn't disable it : something to change in the current code.
• xapi doesn't manage it : nothing to do, it is already the case.

If we consider we need proper clock sync before starting xapi :

• host-installer should enable it with NTP : the first xapi boot will be with synced clock, nothing to do in the current code.
• xapi manage it : the unit is owned by xapi (as chronyd) and xapi should manage it, something to change in the current code.
• xsconsole shouldn't disable it as it is owned by xapi : something to change in the current code.

For xsconsole, in both cases, it means we shouldn't disable the unit.
So I am keeping the line removed for now.

[semarie]

For reference, I opened xapi-project/xen-api#7363

[semarie]

Last push:

• get active NTP servers from XAPI (and not anymore from chronyc)
• in AdjustNTPForStaticNetwork function, restore previous logic
• in Network pane, use xsconsole names in the output for NTP mode instead of XAPI names
• chronyd service management is still removed : safe as already done by xapi
• chrony-wait service management is still removed : see rational in comment