On Tue, Mar 13, 2018 at 5:24 PM, Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:

>
>
> On Tue, Mar 13, 2018 at 4:02 PM, Christian Ehrhardt <
> christian.ehrha...@canonical.com> wrote:
>
>>
>>
>> On Tue, Mar 13, 2018 at 2:50 PM, Miroslav Lichvar <mlich...@redhat.com>
>> 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
or
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-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 Ehrhardt
>> Software Engineer, Ubuntu Server
>> Canonical Ltd
>>
>
>
>
> --
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd
>



-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Reply via email to