feat: add manage option leapsectz

[brakkio86]

Enhancement: support leapsectz option

Reason: this option is mandatory in order to manage leap second situation

Result: new option available

Issue Tracker Tickets (Jira or BZ if any):

[mlichvar]

Clients normally accept leap second information from their servers. The leapsectz option is mainly useful to set the TAI-UTC offset of the system clock. A potential issue is incompatibility with leap-smearing servers.

[richm]

Clients normally accept leap second information from their servers. The leapsectz option is mainly useful to set the TAI-UTC offset of the system clock. A potential issue is incompatibility with leap-smearing servers.

If we document this in the README, is it ok to allow this feature to be supported?

[richm]

Clients normally accept leap second information from their servers. The leapsectz option is mainly useful to set the TAI-UTC offset of the system clock. A potential issue is incompatibility with leap-smearing servers.

If we document this in the README, is it ok to allow this feature to be supported?

@mlichvar ^^^

[mlichvar]

A warning about imcompatibility with leapsmearing servers would be nice.

However, I don't like the chrony-specific variable name. Would something like local_leap_source as a boolean work better? This would open up the possibility for support with ntpd, which has the leapfile file directive and some systems have the leap file included with their tzdata at known location.

The support for leapsectz directive was added long time ago. Is there other reason for having the >= 4.0 conditional?

[richm]

ping - any update?

[richm]

ping - any update? Can we close this?

[brakkio86]

Hello,

The support for leapsectz directive was added long time ago. Is there other reason for having the >= 4.0 conditional?

My fault, I didn't find when whas introduced and then I put this check. Now I verify and removed the conditional.

[brakkio86]

A warning about imcompatibility with leapsmearing servers would be nice.

I've added the documenation and warning section.

[richm]

Do we need this PR at all? Can you use timesync_chrony_custom_settings https://github.com/linux-system-roles/timesync#role-variables:

timesync_chrony_custom_settings:
  - "leapsectz right/UTC"

?

[brakkio86]

Do we need this PR at all? Can you use timesync_chrony_custom_settings https://github.com/linux-system-roles/timesync#role-variables:

timesync_chrony_custom_settings:
  - "leapsectz right/UTC"

?

Yes, it could be use. In my philosofy, I prefer explicit setting.

[richm]

Do we need this PR at all? Can you use timesync_chrony_custom_settings https://github.com/linux-system-roles/timesync#role-variables:

timesync_chrony_custom_settings:
  - "leapsectz right/UTC"

?

Yes, it could be use. In my philosofy, I prefer explicit setting.

Either way is fine with my. One problem with having an explicit setting is that there is a chance of a duplicate entry. For example, if the user specifies

timesync_chrony_leapsectz: "right/UTC"
...
timesync_chrony_custom_settings:
  - "leapsectz left/UTC"

then I think the config file will have both settings. Yes, this is an unlikely scenario, but if you have a complex inventory with multiple hosts and host groups https://docs.ansible.com/ansible/latest/inventory_guide/index.html then you may have a "general" setting in one file with

timesync_chrony_custom_settings:
  - "leapsectz left/UTC"

and a host/region specific setting timesync_chrony_leapsectz: "right/UTC" and will have to figure out how the rules of precedence merge these values for a given host.

Of course we will document in the README something like "Do not use both timesync_chrony_leapsectz and have leapsectz in timesync_chrony_custom_settings".

Do we need to add code to the role to check if timesync_chrony_custom_settings contains leapsectz if timesync_chrony_leapsectz is set?

[richm]

closing due to inactivity