[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.


[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-requ...@chrony.tuxfamily.org with 
"unsubscribe" in the subject.
                  For help email chrony-dev-requ...@chrony.tuxfamily.org with 
"help" in the subject.
                  Trouble?  Email listmas...@chrony.tuxfamily.org.




--
Christian EhrhardtSoftware Engineer, Ubuntu Server
Canonical Ltd




--
Christian EhrhardtSoftware Engineer, Ubuntu Server
Canonical Ltd




--
Christian EhrhardtSoftware Engineer, Ubuntu Server
Canonical Ltd

Reply via email to