From 484ea48a127ea3991e75e6b8ff375b4f21965a08 Mon Sep 17 00:00:00 2001 From: Elisamara Aoki Goncalves Date: Thu, 20 Apr 2023 15:14:37 -0300 Subject: [PATCH] O-RAN Spec Compliant Timing API Notification - v1 compatibility (dsR8) Story: 2010538 Task: 47862 Signed-off-by: Elisamara Aoki Goncalves Change-Id: I6f38e4e34371dcf9ae71d27286731633a41d3fa8 --- .../kubernetes/install-ptp-notifications.rst | 58 +++++++++++-------- ...ation-with-notification-client-sidecar.rst | 6 ++ .../kubernetes/ptp-notifications-overview.rst | 25 ++++++++ 3 files changed, 65 insertions(+), 24 deletions(-) diff --git a/doc/source/admintasks/kubernetes/install-ptp-notifications.rst b/doc/source/admintasks/kubernetes/install-ptp-notifications.rst index 52a06a674..c3629221c 100644 --- a/doc/source/admintasks/kubernetes/install-ptp-notifications.rst +++ b/doc/source/admintasks/kubernetes/install-ptp-notifications.rst @@ -38,10 +38,9 @@ API. **v2 API** -The API conforms to O-RAN.WG6.O-Cloud Notification API-v02.01 with the -exception of the /././sync endpoint limitation. Using the v2 API, multiple -``ptp4l`` instances can be tracked for independent |PTP| Sync State and |PTP| -Clock Class notifications. +The API conforms to O-RAN.WG6.O-Cloud Notification API-v02.01. Using the v2 +API, multiple ``ptp4l`` instances can be tracked for independent |PTP| Sync +State and |PTP| Clock Class notifications. The application monitors the following services: @@ -55,12 +54,6 @@ The application monitors the following services: - Overall System Sync State -**Limitations** - -The |O-RAN| Cloud Notification defines a /././sync API v2 endpoint intended to -allow a client to subscribe to all notifications from a node. This endpoint is -not supported in |prod-long| Release 22.12. A specific subscription for each -resource type must be created instead. .. rubric:: |context| @@ -128,23 +121,24 @@ For example, follow the steps below: #. Create a yaml file and update the fields that require Helm overrides. - .. code-block:: + .. code-block:: none ~(keystone_admin)]$ cat notification-override.yaml - ptptracking: - ptp4lServiceName: True - phc2sysServiceName: True - ts2phcServiceName: True - log_level: INFO - control_timeout: 2 - device: - holdover_seconds: 15 - poll_freq_seconds: 2 - osclock: - holdover_seconds: 15 - overall: - holdover_seconds: 15 + ptptrackingv2: + enabled: True + ptp4lServiceName: True + phc2sysServiceName: True + ts2phcServiceName: True + log_level: INFO + control_timeout: 2 + device: + simulated: false + holdover_seconds: 15 + osclock: + holdover_seconds: 15 + overall: + holdover_seconds: 15 where the values are: @@ -196,6 +190,22 @@ For example, follow the steps below: cycles. The ``holdover_seconds`` value should be configured to match the validated holdover time provided by the device manufacturer. + #. To configure the ``ptp-notification`` v1 API, include the following in + the ``notification-override.yaml`` file. Ensure that values are updated + to match the configured instance names on your system. + + .. code-block:: none + + ptptracking: + enabled: True + ptp4lSocket: /var/run/ptp4l-instancename + ptp4lServiceName: ptp4l-instancename + phc2sysServiceName: phc2sys-instancename + logging_level: INFO + device: + holdover_seconds: 15 + poll_freq_seconds: 2 + #. View existing values. .. code-block:: none diff --git a/doc/source/guest_integration/kubernetes/integrate-application-with-notification-client-sidecar.rst b/doc/source/guest_integration/kubernetes/integrate-application-with-notification-client-sidecar.rst index 29544b097..18897cc16 100644 --- a/doc/source/guest_integration/kubernetes/integrate-application-with-notification-client-sidecar.rst +++ b/doc/source/guest_integration/kubernetes/integrate-application-with-notification-client-sidecar.rst @@ -39,6 +39,12 @@ application and the Sidecar communicate via a REST API. See the figure below. :start-after: note-begin :end-before: note-end +To use the v1 API, deploy ``starlingx/notificationclient-base:stx.5.0-v1.0.4`` +as the sidecar container. + +To use the v2 API, deploy ``starlingx/notificationclient-base:stx.9.0-v2.1.1`` +as the sidecar container. + .. rubric:: |prereq| The following prerequisites are required before the integration: diff --git a/doc/source/guest_integration/kubernetes/ptp-notifications-overview.rst b/doc/source/guest_integration/kubernetes/ptp-notifications-overview.rst index afa389fc9..17baac97b 100644 --- a/doc/source/guest_integration/kubernetes/ptp-notifications-overview.rst +++ b/doc/source/guest_integration/kubernetes/ptp-notifications-overview.rst @@ -127,3 +127,28 @@ manifest to include these parameters. timeoutSeconds: 3 EOF + +**Container images and API compatibility** + +The ``ptp-notification`` provides a v1 API for backwards compatibility with +client applications deployed on |prod| |prod-ver|, as well as a v2 API for +O-RAN Spec Compliant Timing notifications. By default, ``ptp-notification`` +deploys two ``notificationservice-base`` containers to support these APIs. +Users must decide which API they will use by deploying the appropriate +``notificationclient-base`` image as a sidecar with their consumer application. + +- The v1 API uses ``starlingx/notificationservice-base:stx.9.0-v2.1.1`` + + - Compatible with the image: + ``starlingx/notificationclient-base:stx.5.0-v1.0.4`` + +- The v2 API uses ``starlingx/notificationservice-base-v2:stx.9.0-v2.1.1`` + + - Compatible with the image: + ``starlingx/notificationclient-base:stx.9.0-v2.1.1`` + +Upgrades of |prod| |prod-ver| to the next patch will automatically upgrade the +``ptp-notification`` application and deploy both the v1 and v2 API containers. +Consumer applications determine which API they interact with based on the +version of ``notificationclient-base`` that is deployed along side their +application.