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
