Re: [chrony-dev] [PATCH v3] main: add -X to fall back if time is not adj

On Tue, Mar 13, 2018 at 5:24 PM, Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx> wrote:

On Tue, Mar 13, 2018 at 4:02 PM, Christian Ehrhardt <christian.ehrhardt@canonical.com> wrote:

On Tue, Mar 13, 2018 at 2:50 PM, Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:
On Tue, Mar 13, 2018 at 12:17:41PM +0100, Christian Ehrhardt wrote:
> The important part is the lack of knowledge of the target systems
> capabilities.
> They are:
> - not detectable by some install paths, for example
> - install in VM with behavior A onto phys disk but reboot host into said
> disk
> - installing on a remote disk mounted chroot, which might be totally
> different when this runs.
> - ...
> - Several tools/configs might add/remove capabilities from a system later
> on in the lifecycle
> - Some move machines between places with different capabilities

Does any of this change the requirement on synchronization of the
system clock?

Something has to install and configure the chronyd service to run as
an NTP server on the system. (By default it's just a client.) What
does decide if -x/-X is added to the options?

For above cases the example would be a tool that needs time synchronization, pulls in chrony but the tool wants to ensures it runs wherever it ends up (with clock sync if it can, but at least the NTP server part if it can't).

There are even discussions ongoing if for Ubuntu we would want to default to -X in general (as default in a config file).

> - ...
> The TL;DR of the "motivation" is: the inability to decide if using "-x" is
> right or not (at any time).

I think the same applies to -X.

No it's not.
The users that started this with a Launchpad bug would always set -X for their case.
They would never want to set "-x" or "", but "-X" would be just what they want.

> With just "-x" available this leads to one of the following:
> A) So if one sets "-x" it will NEVER sync the clock even if the system
> would be capable to do so.

The system may be capable, but nothing requires the clock to be
synchronized, right? Otherwise it would make no sense to use any of
the -X/-x options.

Partially correct, nothing "hard requires" the clock to be synced, but it is "preferred" to sync it if possible so setting -x would waste that.

> BTW - in case it might be better to discuss interactive - I'm "cpaelzer" on
> freednode IRC.
> If there is a common place chrony matters are usually discussed (other than
> the ML) that would be nice to know - I haven't found a hint about it on the
> web page.

I'm mlichvar on #ntp. People discuss chrony there occasionally.

Thanks, will join there shortly to hopefully get our intentions fully clear in a discussion there.

In our discussions we came up with an alternate approach that I might code up.
I'll outline this in a following paragraph, but I must admit I really think -X is much cleaner as it has:
- no service name confusion
- more clear messaging on Initialisation what failed
- the ability for those who want the "NTP serve in anyway, sync time if able to" to opt into that

[...]

We continued our discussion hoping that the remaining misunderstanding will be resolved by either:

a) me seeing a way how I could resolve the use cases I (my ubuntu bug reporters actually) face without -X

b) making everyone understand what the use case is to need -X implemented

For b) here an excerpt of our chat log that I wanted to share more widely to keep everybody in the loop.

[...]

[17:24] <cpaelzer> mlichvar: -X really is what I (and my bug reporters) need

[17:25] <mlichvar> I still don't understand why

[17:25] * cpaelzer fails at explaining it seems

[17:25] <cpaelzer> if you deploy chrony to a random system

[17:25] <cpaelzer> and you don't know if it is able to sync local time

[17:26] <cpaelzer> but you'd prefer it does if it can

[17:26] <mlichvar> why would you prefer that?

[17:26] <cpaelzer> well maybe that is my misunderstanding

[17:26] <mlichvar> instead of requiring it

[17:27] <cpaelzer> mlichvar: let me try to explain just this part "why to we prefer instead of requiring it"

[17:28] <cpaelzer> We have two cases how this can run

[17:28] <cpaelzer> 1. if this runs on a Host that can set time, it has to be in sync with what it serves time to - so it needs to set local time

[17:28] <cpaelzer> so for #1 it is a requirement

[17:29] <cpaelzer> 2. if it runs in a container then we know the host is already synced to the same source that chrony in the container gets its time (so I got told)

[17:29] <cpaelzer> so for #2 it is not required, because the host does already keep us in sync

[17:29] <cpaelzer> so it actually is required, but provided implicitly

[17:30] <cpaelzer> now if I ask them to set -x all the time, then if running on a host that can set time they can be out of syns

[17:30] <cpaelzer> but if I ask them to not set -x then they fail to run in containers

[17:30] <cpaelzer> mlichvar: did it make more sense now?

[17:31] <mlichvar> if you limit all possible cases to the two, then yes

[17:31] <cpaelzer> and -X would be the best of both worlds for them

[17:31] <cpaelzer> in #1 they sync time and stay with their nodes

[17:31] <cpaelzer> in #2 the host would keep them in sync but they can still serve time from there

[17:31] <cpaelzer> I already made clear that I'd not recommend serving time from there

[17:32] <cpaelzer> but it is a use case for them, which makes me discussing -X with you hoping you understand our needs

--
Miroslav Lichvar

--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxamily.org with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxamily.org with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxg.

--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Christian Ehrhardt

Software Engineer, Ubuntu Server

Canonical Ltd