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

On Tue, Mar 13, 2018 at 5:54 PM, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:

[17:25] * cpaelzer fails at explaining it seems
[17:25] <cpaelzer> if you deploy chrony to a random system

If you have a random system and you have no idea whether or not its clock is
good or a complete piece of merde, why would you want it acting as a server
for anything? That is liable to cause mass confusion to the clients who have
no idea whether or not to trust their server.

Sorry, it was just a simplification to explain more easily.

This is not an important detail to the discussion itself IMHO, but for the sake of completeness, something like:

s/random/a system where you have no means to check/ensure that either on install time or for the lifetime of the system it will have the capability to adjust the local clock. But even in case it's clock would be a piece of merde let it get somewhat reliable time from network sources and spread that locally to some peers to keep them in sync among each other/

[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 EhrhardtSoftware Engineer, Ubuntu Server
Canonical Ltd

--
Christian EhrhardtSoftware Engineer, Ubuntu Server
Canonical Ltd

--
Christian EhrhardtSoftware Engineer, Ubuntu Server
Canonical Ltd

Christian Ehrhardt

Software Engineer, Ubuntu Server

Canonical Ltd