[release-4-18] OCPBUGS-59883: When Locking PTP Source to One NIC With Dual NIC PTP Synchronization Configured, Incorrect Clock Class Reported via REST API

[aneeshkp]

This commit implements logic to correctly update the clock class
when a FAULTY/RECOVERY condition of the port is detected.
Summary :
Ensure PMC clock-class queries run at most once per configName concurrently.
Trigger PMC on port Faulty/Holdover and recovery transitions to refresh GM class.
Run PMC polling outside the log scanner so we still update when ptp4l is silent.

What’s changed
Per-config single-flight guard:
Added a shared sync.Map keyed by configName to serialize updateClockClass across processes referencing the same config.
updateClockClass now CASes on the shared guard and logs when a run is skipped.
Cleanup: guard entry is removed on cmdStop() of the corresponding process.

Faulty/Holdover and recovery handling:
When the clock enters HOLDOVER or LOCKED without a specific iface, we now trigger updateClockClass (after a short delay) so GM class is refreshed on port fault/recovery events, not just on normal offset updates.
PMC polling outside the scanner:
Introduced/relied on a background loop that consumes a pmcCheck flag and calls updateClockClass independent of log scanner activity.
A periodic ticker sets pmcCheck for ptp4l processes; the background loop handles the PMC call even if ptp4l is not emitting logs.

Release note
Improve clock class update robustness: deduplicate PMC queries per config, update on Faulty/Holdover and recovery, and poll PMC independently of log output.

[openshift-ci-robot]

@aneeshkp: This pull request references Jira Issue OCPBUGS-59883, which is invalid:

• release note text must be set and not match the template OR release note type must be set to "Release Note Not Required". For more information you can reference the OpenShift Bug Process.
• expected Jira Issue OCPBUGS-59883 to depend on a bug targeting a version in 4.19.0, 4.19.z and in one of the following states: VERIFIED, RELEASE PENDING, CLOSED (ERRATA), CLOSED (CURRENT RELEASE), CLOSED (DONE), CLOSED (DONE-ERRATA), but no dependents were found

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

In response to this:

This commit implements logic to correctly update the clock class
when a FAULTY/RECOVERY condition of the port is detected.
Summary :
Ensure PMC clock-class queries run at most once per configName concurrently.
Trigger PMC on port Faulty/Holdover and recovery transitions to refresh GM class.
Run PMC polling outside the log scanner so we still update when ptp4l is silent.

What’s changed
Per-config single-flight guard:
Added a shared sync.Map keyed by configName to serialize updateClockClass across processes referencing the same config.
updateClockClass now CASes on the shared guard and logs when a run is skipped.
Cleanup: guard entry is removed on cmdStop() of the corresponding process.

Faulty/Holdover and recovery handling:
When the clock enters HOLDOVER or LOCKED without a specific iface, we now trigger updateClockClass (after a short delay) so GM class is refreshed on port fault/recovery events, not just on normal offset updates.
PMC polling outside the scanner:
Introduced/relied on a background loop that consumes a pmcCheck flag and calls updateClockClass independent of log scanner activity.
A periodic ticker sets pmcCheck for ptp4l processes; the background loop handles the PMC call even if ptp4l is not emitting logs.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[vitus133]

Looks good for 4.18.
For 4.20 we need to make sure this code is not called in the T-BC setting (the upstream already has this check). Why do we start the fixing from 4.18 and not from the upstream?

[nocturnalastro]

Might be best to use consume for all times of setting it to false to make it easier to search of when it happens

[aneeshkp]

made changes as suggested

[nocturnalastro]

Would it be better to use atomic.Bool to properly signal what this used for.

[aneeshkp]

ok , let me try to replace with bool for better readability

[aneeshkp]

done

[openshift-ci]

@aneeshkp: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[nocturnalastro]

/label backport-risk-assessed

[nocturnalastro]

/ltgm

[nocturnalastro]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: aneeshkp, nocturnalastro

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [aneeshkp]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[aneeshkp]

/verified later @Bonnie-Block

[openshift-ci-robot]

@aneeshkp: This PR has been marked to be verified later by @Bonnie-Block.

In response to this:

/verified later @Bonnie-Block

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.