On Tue, Mar 13, 2018 at 5:54 PM, Bill Unruh <un...@physics.ubc.ca> 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-requ...@chrony.tuxf
>> amily.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
>>
>>


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Reply via email to