docs/doc/source/guest_integration/kubernetes/ptp-notifications-overview.rst

PTP Notifications Overview

supports applications that rely on for synchronization. These applications are able to receive status notifications from hosting the application.

provides a Sidecar, which runs with the hosted application in the same pod and communicates with the application via a REST API.

supports the following features:

• Provides the capability to enable application(s) subscribe to status notifications and pull for the state on demand.
• Uses a REST API to communicate notifications to the application.
• Enables operators to install the ptp-notification-armada-app, Sidecar container, and the application supporting the REST API. For more information, see, https://docs.starlingx.io/api-ref/ptp-notification-armada-app/index.html.
• Supports the ptp4l module and port that is configured in Subordinate mode (Secondary mode).
• The notification Sidecar container can be configured with a Liveness Probe, if required. See, Liveness Probe <liveness-probe> for more information.
• The status notifications are derived based on the following conditions:

Clock Status	Status	Description
Freerun	Clock is out of sync state	If portState is not "SECONDARY" or ClockClass value is NOT "6, 7 or 135" or timeTraceable flag is FALSE. If holdover time exceeds its provided value. If PMC, ptp4l.conf, ptp4l or phc2sys are not accessible.
Locked	Clock is in sync state	If portState is "SECONDARY" and ClockClass value is "6, 7 or 135" and timeTraceable flag is TRUE and PMC, ptp4l.conf, ptp4l or phc2sys are accessible.
Holdover	Clock is in holdover state	If the state is transitioned from "Locked" to "Freerun" AND phc2sys is accessible, and holdover time does not expire.

Integrated Containerized Applications

• Applications that rely on for synchronization have the ability to retrieve the relevant data that indicates the status of the PHC clock related to the worker node that the application is running on.
• Once an application subscribes to notifications it receives the initial data that shows the PHC synchronization state, and receives notifications when there is a state change to the sync status and/or per request for notification (pull).

The figure below describes the subscription framework for notifications.

Liveness Probe

The notification Sidecar container can be configured with a Liveness probe, if required. You can edit the Sidecar values in the deployment manifest to include these parameters.

Note

Port and timeout values can be configured to meet user preferences.

cat <<EOF >
items:
spec:
  template:
    spec:
      containers:
        livenessProbe:
          exec:
            command:
            - timeout
            - "2"
            - curl
            - http://127.0.0.1:8080/health
          failureThreshold: 3
          periodSeconds: 3
          successThreshold: 1
          timeoutSeconds: 3
EOF