Right now, ptp-notification app is using beta
versions of the Fluxcd and Helm APIs, and for
this reason, some warnings are being thrown.
This change aims to update api versions, removing
beta values following this logic:
Fluxcd:
- source.toolkit.fluxcd.io/v1beta1
+ source.toolkit.fluxcd.io/v1
Helm:
- helm.toolkit.fluxcd.io/v2beta1
+ helm.toolkit.fluxcd.io/v2
No changes to yaml file structure are required
for this change.
Test Plan:
PASS: Build ISO & Bootstrap AIO-SX
PASS: Upload and apply ptp-notification app
PASS: Confirm that sysinv.log does not have any
warnings about beta versions related to
ptp-notification.
Story: 2011129
Task: 50454
Change-Id: I8cfd9190294a6047f1d3482f7596b2577a99bcf9
Signed-off-by: Edson Dias <edson.dias@windriver.com>
The metadata field for behavior was misspelled as "behaviour", resulting
in ptp-notification omitting the "platform_managed_app" option.
Test plan:
Pass: Verify ptp-notification build and deploy
Pass: Verify app upload/apply/override/remove/delete
Pass: Verify ptp-notification app requests to be platform managed
Closes-bug: 2065428
Signed-off-by: Cole Walker <cole.walker@windriver.com>
Change-Id: Ia0cb090c3b177994fc1d9f317b84fd93bf63061d
Enable auto-versioning of helm charts to ensure the FluxCD helm
controller recognizes chart changes.
To guarantee the helm chart version is incremented when a helm chart
change is submitted, the following is implemented:
- Provide a top level hierarchy for helm charts to differentiate
between upstream and custom charts: helm-charts/{custom,upstream}
- Arrange exiting helm chart in appropriate helm-charts location.
Custom for helm charts built and maintained in this repository.
Upstream for directly used and/or directly used plus patched.
- stx-APP-helm now contains only manifests and final application
packaging rules. No custom helm charts should be delivered here.
- Establish a new package(s) for the custom or upstream helm chart(s).
- Enforce a baseline version for all helm charts; eg 'APP-helm'.
Maintain current rev counts for all new packages, where applicable.
- Update 'stx-APP-helm' to:
- Update the build dependencies to include the new helm chart package
and remove dependency on helm
- Update the rules to remove building the dependency APP helm
chart(s) and automatically update the chart versions in the
FluxCD helmrelease.yaml files.
Test Plan:
PASS - Build all packages generating an application tarball verifying
all versions on the charts and application make sense.
PASS - Introduce temporary chart changes and ensure that the versions
increment as expected.
PASS - Validate basic application lifecycle operations:
upload/apply/remove/delete.
Story: 2010929
Task: 49614
Change-Id: Ied7ff31b03b0b22d099649c91f712e6f9aafcd63
Signed-off-by: Joshua Reed <joshua.reed@windriver.com>
Add the minimum Kubernetes version supported to the application metadata
file.
The minimum Kubernetes version is set to 1.24.4 and should be changed
accordingly for future application updates.
The "supported_k8s_version:minimum" field is optional but it will become
mandatory in the near future.
This also contains a fix to properly trigger the Tox metadata checks.
Test Plan
PASS: build-pkgs && build-image
Story: 2010929
Task: 49500
Change-Id: I38d52f161946c616e82647401562577b4699c1f6
Signed-off-by: Igor Soares <Igor.PiresSoares@windriver.com>
This change will automatically adjust versioning of the application
tarball and python plugins to reflect the same version reported by
SW_VERION in /etc/build.info.
Test plan:
PASS: build-pkgs -a & build-image
PASS: Confirm that the tarball version matches the platform version
PASS: Apply application
Story: 2010929
Task: 49349
Change-Id: I33e6dc77db82bcba2381ac604272ed8550ae78d8
Signed-off-by: Igor Soares <Igor.PiresSoares@windriver.com>
Modify code to conform to flake8 and pylint.
Jobs are now flake8, pylint, py39 and metadata.
Add bindep.txt
Deprecate old py27,py36 testenvs from tox.ini in
the python package folder in favor of py39 instead.
However, keep the root folder tox.ini py36 job because
that test is checking code other than the python package.
Test Plan
PASS - All zuul jobs pass as expected.
Story: 2010929
Task: 49280
Change-Id: Ic64ad41a3bf6454dd9ea0f6e862c3b31a0541660
Signed-off-by: Reed, Joshua <Joshua.Reed@windriver.com>
Add support to 'app.starlingx.io/component' to be overwritten
by user override, with possible values being 'platform' and
'application'. With 'platform' being the default value. This
change will also restart the pods if the label changes.
Test Plan:
PASS: upload/apply/remove/delete/update ptp-notification.
PASS: Install ptp-notification and check if pods have the label
'app.starlingx.io/component' with the value 'platform'.
PASS: Change the value of the labels.isApplication to true using
"system helm-override-update" and check, if after re-applying
the app, the label 'app.starlingx.component' changes to
application' in the pods.
PASS: Use 'system application-apply ptp-notification' when there is
a change to be applied to 'app.starlingx.component' and verify if the
pod is restarted.
PASS: If "labels.isApplication" is updated with a value other than
true or false, the label on the pods "app.starlingx.io/component"
will not change.
Story: 2010612
Task: 49132
Change-Id: I2f8586cbb7ceac75892af41b7120db6c189cdafa
Signed-off-by: David Barbosa Bastos <david.barbosabastos@windriver.com>
In order to better support the default configuration when
ptp-notification is deployed on a BC, the ptp4lClockClassLockedList
values should in include 135 as a locked clockClass.
This change ensures that classes 6, 7 and 135 are considered acceptable
for the ptp-notification locked state by default, with the ability to
override the acceptable clockClasses available to the user.
Test plan:
PASS: Build ptp-notification helm charts
PASS: Deploy ptp-notification
PASS: v1 api - test ptp4lClockClassLockedList with the default list
PASS: v2 api - test ptp4lClockClassLockedList with the default list
Partial-bug: 2033539
Signed-off-by: Cole Walker <cole.walker@windriver.com>
Change-Id: Ic569c373dc2ddf1771e83b12832ef1460266c93a
To allow more flexibility to the user, The following PTP parameters
are being exposed to Helm Charts overrides configuration:
ptp-notification-v1:
- ptp4lClockClassLockedList
ptp-notification-v2:
- ptp4lClockClassLockedList
- phc2sysToleranceThreshold
Test Plan:
PASS: Build containers and helm charts
PASS: Deploy ptp-notification
PASS: v1 api - test ptp4lClockClassLockedList with the default,
non-default and invalid lists
PASS: v2 api - test ptp4lClockClassLockedList with the default,
non-default and invalid lists
PASS: v2 api - test phc2sysToleranceThreshold with commandline option
PASS: v2 api - test phc2sysToleranceThreshold with config file
Closes-bug: 2033539
Change-Id: I7dc915d99a91ff405c4cca4f1e1c1bf3a3559a4e
Signed-off-by: Caio Bruchert <caio.bruchert@windriver.com>
Check for the presence of a phc2sys source clock when phc2sys HA mode is
enabled and set lock state accordingly if no source is found.
For ptp-notification-v2, this change affects the os clock state
tracking. If HA mode is enabled and no clock source is present, proceed
to transition to HOLDOVER and FREERUN states as required.
For ptp-notification-v1, there has never been support for checking
whether phc2sys is synced/locked, only whether the service is running.
In order to leave the default behaviour the same, a user supplied helm
override PHC2SYS_COM_SOCKET can be set. By providing a path to the
phc2sys socket, ptp-notification-v1 will now check to see if a source
clock is present for phc2sys and transition to HOLDOVER and FREERUN if
no source is found. When the PHC2SYS_COM_SOCKET value is not provided,
ptp-notification-v1 maintains the default behaviour and does not check
for the presence of a source clock.
Test Plan:
PASS: Build containers and helm charts
PASS: Deploy ptp-notification
PASS: v2 api - test state transition when source clock is
lost/returns
PASS: v1 api - validate that default behaviour is unchanged when
phc2sys com socket is not set
PASS: v1 api - verify state transition when phc2sys source clock is
lost/returns
Story: 2010723
Task: 48514
Signed-off-by: Cole Walker <cole.walker@windriver.com>
Change-Id: I769d36df024d207bf0f70efd11d68d8a8809f713
Updated the logic in ptptracking_start.py to handle a case where the
application is upgraded but helm overrides are not present.
If helm overrides are present, there is no change in behaviour.
If helm overrides are absent, attempt to locate ptp4l and phc2sys
configs in known locations and start with those.
Print log messages indicating that the configs were auto detected
and that helm overrides can be set if auto-detection is incorrect or
unsuccessful.
Bonus fix: corrected the tox path used to auto detect unit tests, as
this was missed when moving from notificationservice-base to
notificationservice-base-v2
Test-plan:
PASS: Build and deploy application tarball
PASS: Pods start correctly when overrides are present and when they are
absent
Story: 2010538
Task: 47740
Signed-off-by: Cole Walker <cole.walker@windriver.com>
Change-Id: I25df407effbffc03e444573233058f3d3180e706
Use the new get_rpc_client API to handle the RCPClient
instantiation.
This new API was added into oslo.messaging here [1].
[1] https://review.opendev.org/c/openstack/oslo.messaging/+/862419
Closes-bug: 2011620
Signed-off-by: Andre Mauricio Zelak <andre.zelak@windriver.com>
Change-Id: I2322d0bb49b342f8eec49f599257f9dac83b3d8a
This change updates the metadata of the ptp-notification application
tarball to mark the app as platform managed and eligible for automatic
upgrades. The application framework will now properly upgrade
ptp-notification when a newer version is installed on a system.
Test plan:
PASS: Build and deploy updated ptp-notification
PASS: Patch system to update ptp-notification application, verify that
app is automatically upgraded.
Story: 2010538
Task: 47583
Signed-off-by: Cole Walker <cole.walker@windriver.com>
Change-Id: I3e42a58f9d01fbfdfadf2d733fc3411c6732384b
Currently, the debian build system produces a debian package version
with the format: "1.0-1.stx.<revision>"
The rules file then parses this deb pkg version at build time
to produce the app tarball version, which always comes up to
be "1.0-1" at this time [1]. This commit changes the app tarball
version calculation so that the resulting tarball version will
be "1.0-<revision>" [2].
This correction is necessary because the application framework
cannot update an app between instances with the same version.
This commit is part of a set of commits updating the app tarball
version calculation to all apps based off of [3].
[1]: /usr/local/share/applications/helm/<APPNAME>-1.0-1.tgz
[2]: /usr/local/share/applications/helm/<APPNAME>-1.0-<N>.tgz
[3]: https://review.opendev.org/c/starlingx/cert-manager-armada-app/+/872628
Test Plan:
pass - build-pkg
pass - tarball version updated
Story: 2010542
Task: 47530
Signed-off-by: Leonardo Fagundes Luz Serrano <Leonardo.FagundesLuzSerrano@windriver.com>
Change-Id: I4c983e812501765da54cc07cbb5bceb7c3f94cde
The existing logic in the daemonset template was removing several of the
required volume mounts and resulting in a failure to create the pods.
The fix preserves the volume mounts even if the v1 notification is
disabled.
Test-plan:
PASS: Build and deploy ptp-notification
PASS: Enable/disable v1/v2 api containers
Story: 2010538
Task: 47557
Signed-off-by: Cole Walker <cole.walker@windriver.com>
Change-Id: Iee6dacbf36e038c61de9450ca15e5cdc135d97aa
Fixed versioning and adjusted some build files
to bring them as close to a standard as possible.
- Removed centos files
- Added version tracking via GITREVCOUNT
- Fixed mismatch in plugin name, set to python3-k8sapp-<app>
- Standardized plugin debian files (rules, *.install)
- Plugin wheels saved to /plugin instead of /plugin/<app>
Test Plan:
PASS - Build-pkgs -a
PASS - Build-image
PASS - Install, bootstrap, unlock
PASS - app tarball contains wheel file
PASS - wheel versioning updated properly
Story: 2010542
Task: 47186
Signed-off-by: Leonardo Fagundes Luz Serrano <Leonardo.FagundesLuzSerrano@windriver.com>
Change-Id: I0e8e26d3baf364a8bd6b2e7b9e23c7dd3d91634b
Update the notificationservice-base-v2 container image to use a v2
identifier on rabbitmq topics. This allows v1 and v2 messages to be
handled separately. Update the notificationclient image to use the v2
identifier as well.
The v1 notificationservice-base will continue to use the default
rabbitmq topics with no additional identifier. This is compatible with
the following notificationclient-base image:
starlingx/notificationclient-base:stx.5.0-v1.0.4
This change also updates the daemonset to deploy both v1 and v2
notificationservice-base images and provides a helm overrided to allow
either one to be disabled.
Finally, update the notificationclient-base Dockerfile to pin the
version of sqlalchemy to 1.4.12. This is the same version used for the v1
client, and the latest 2.x.x version of sqlalchemy has changes which
break notificationclient-base.
Test plan:
PASS: Build all container images
PASS: Build and deploy ptp-notification application
Pass: Test ptp-notification Pull, Subscribe, Delete functionality for v1
and v2
Story: 2010538
Task: 47285
Task: 47286
Change-Id: Ib033661f496439f62af785f8f37b1069ccb74ba1
Set reconciliation interval for all flux helm resources to 1m
to allow it to manage resources by itself in a reasonable time
interval.
Test Plan (tested as part of [1]):
PASS: bootstrap
PASS: unlocked enabled available
PASS: apps applied
PASS: inspect flux pod logs for errors
PASS: re-test known trigger for 1996747 and 1995748
PASS: re-test known trigger 1997368
[1] https://review.opendev.org/c/starlingx/config/+/866862
Partial-Bug: 1999032
Signed-off-by: Leonardo Fagundes Luz Serrano <Leonardo.FagundesLuzSerrano@windriver.com>
Change-Id: Ib18917bf18bff5718312ba7dc595d34dad85b6de
Update the image tag for notificationservice-base to
sxt.8.0-v2.0.2
Story: 2010056
Task: 46993
Depends-on: https://review.opendev.org/c/starlingx/root/+/866609
Signed-off-by: Cole Walker <cole.walker@windriver.com>
Change-Id: I111cf202ab4a45ad0c35704404cd7f1cb992e451
The PTP tracking container ("notificationservice-base") used hard-coded
path in the reference to ptp4l, phc2sys and ts2phc configuration files,
which led to bad initialization in a Debian environment (regardless the
container is CentOS-based, since the path is mapped to the host).
This change tests for the correct path, either in ./linuxptp/ptpinstance
(Debian) or ./ptpinstance (CentOS).
It also fixes an issue when there is no PHC interface defined, neither
in the command line or in the phc2sys configuration file.
BONUS: The logging helper of location service was fixed to properly log
the messages like done already for the other images (notification server
and client). Logging level can now be set also for this container.
Test Plan:
PASS: Built and tested new image for notificationservice-base.
Closes-Bug: #1994192
Signed-off-by: Douglas Henrique Koerich <douglashenrique.koerich@windriver.com>
Change-Id: I7be15b19b9a165a47e12c38deb9eed2b5b7d09ee
Upstream has deprecated 'node-role.kubernetes.io/master'
to use 'node-role.kubernetes.io/control-plane' in k8s 1.24.
Platform and applications need to be updated to use 'control-plane'
with nodeSelector/Tolerations so we may upgrade from 'master'.
This updates pod nodeSelector to use
'node-role.kubernetes.io/control-plane' instead of
'node-role.kubernetes.io/master'.
This updates pod Tolerations to support both:
- 'node-role.kubernetes.io/master'
- 'node-role.kubernetes.io/control-plane'
Test Plan:
PASS: In standard lab with additional "control-plane" taint on
controller-1, add ptp notification and registration labels and
ensure that ptp pods run on controller-1.
Story: 2010301
Task: 46669
Signed-off-by: Saba Touheed Mujawar <sabatouheed.mujawar@windriver.com>
Change-Id: I5a4bb2ea3d68431a8a20906fcd8d9675b43a11b2
Update the helm chart value for the notificationservice-base image to
stx.8.0-v2.0.0
The major version uprev is due to the significant API changes to support
O-RAN notification.
Story: 2010056
Task: 46526
Depends-on: https://review.opendev.org/c/starlingx/root/+/860972
Signed-off-by: Cole Walker <cole.walker@windriver.com>
Change-Id: Ia6dc502fc7f24a7cf0f31087939c87a67d1c48db
Update the helm chart value for the notificationservice-base image to
stx.8.0-v1.0.6
Story: 2010056
Task: 46526
Depends-on: https://review.opendev.org/c/starlingx/root/+/860718
Signed-off-by: Cole Walker <cole.walker@windriver.com>
Change-Id: I529446082496d76b8b9376097dd30010bba3c2fd
Fixes two issues:
1.
The CPU usage consumed by monitoring the kern.log file for changes in
the NIC cgu status was found to be excessive. This change reverts that
implementation and returns to a polling approach similar to what was
already used for monitoring ptp4l and os clock statuses. This has been
observed to bring main process in the notificationservice-base image
down from ~60% CPU to ~8-10% CPU utilization.
In the future, a preferrable implementation would be to work with device
driver owners to provide support for udev events, removing the need to
poll the status of devices.
2.
User supplied holdover times for each service type were not being
applied correctly. Updated daemon.py to set the holdover times in the
service context.
This also includes providing a user configurable "CONTROL_TIMEOUT"
parameter to control the frequency of polling. This is a global value
and affects the polling rate for all services.
Test-plan:
PASS: Build and install ptp-notification app and containers
PASS: Observe reduced CPU usage and confirm that GNSS monitoring still
works
PASS: User supplied holdover times work correctly, along with polling
rate
Story: 2010056
Task: 46512
Task: 46513
Signed-off-by: Cole Walker <cole.walker@windriver.com>
Change-Id: Ic0050cc09f5118e7f1c32aa13168084d6456437e
During tests with the ptp-notification app it was observed that a bad
override could crash the startup script of ptptracking (notification
service). This minor change fixes that.
Test Plan:
PASS: Build and deploy new ptptracking image
PASS: Startup of ptptracking container
Story: 2010056
Task: 46496
Signed-off-by: Douglas Henrique Koerich <douglashenrique.koerich@windriver.com>
Change-Id: I659e0e1bc812cca73b34079f4cf207a91843dfdc
Issue: Deploying ptp-notification on multiple nodes does not work
properly when each node has different ptp-instance names configured.
This change allows the ptp-notification pod to discover the ptp services
on each node that it is running on and generate a list of service names
to monitor. This also removes the requirement for users to supply an
override with a list of service names.
A given monitoring type can be disabled by supplying an override value
of "False" and ptp-notification will not track it.
Test plan:
PASS: Build and deploy ptp-notification
PASS: Automatically monitor all configured instances
PASS: Disable each instance type independently
Story: 2010056
Task: 46356
Signed-off-by: Cole Walker <cole.walker@windriver.com>
Change-Id: Ieb3ee26b9431e7ac15a7599a69ce9846dce78328
Several improvements and fixes to enable the end-to-end functionality of
all of the components in support of the O-RAN Spec Compliant Timing API
Notification work.
1. Add time stamps to logging for notificationservice and
notificationclient
2. Add support for the "optional" hierarchy in the resource address
which allows the client to query the status of a specific ptp instances.
ie. get the status of instance ptp1 rather than all ptp instances
3. Add a parent key to the returned notification data so that multiple
statuses can be returned to the client with a single notification'
4. Reworked the notificationservice daemonset to start its process
directly rather than using an intermediary script. This allows the
container logs to show properly via kubectl logs and will also allow the
container to crash properly if the program errors out.
5. Reworked the helm values for ptp4l and ts2phc instances to allow
users to supply overrides with multiple instances
Test plan:
PASS: PTP notification v1 compatibility
PASS: GET all v2 resources
PASS: SUBSCRIBE/LIST/DELETE v2 resources
PASS: Build and deploy containers/fluxcd app
Story: 2010056
Task: 46226
Change-Id: Id471fdc0815afdcc5639e81c6457616e268e6cd7
Signed-off-by: Cole Walker <cole.walker@windriver.com>
As part of Armada deprecation we need to remove all Armada application
builds for all applications that have been migrated to FluxCD.
This patch removes the armada app build from centos and debian.
TEST PLAN:
PASS: Build centos
PASS: Build debian
PASS: Install centos
PASS: Install debian
Story: 2009138
Task: 46097
Signed-off-by: Lucas Cavalcante <lucasmedeiros.cavalcante@windriver.com>
Change-Id: I610aa05aa579138390fb5d58bc714e0a3bf76d80
Adds notification functionality for PTP clockClass data and re-works the
overall PTP sync status to allow for multiple ptp4l instances to be
tracked. Each ptp4l instance reports its own sync status and clockClass.
This change moves several static functions out of ptpsync.py and into
the PtpMonitor class. The remaining static functions have been moved
into utils.py
This change retains backwards compatibility allowing for v1 PTP
notifications and subscriptions to continue working while also providing
the v2 functionality required by the ORAN Notification standard.
This change also provides an override value for the logging level
exposed via a helm chart override.
Testing:
PASS: GET and Subscribe functions for each notification type
PASS: Multiple PTP instance support
Story: 2010056
Task: 46038
Task: 46039
Signed-off-by: Cole Walker <cole.walker@windriver.com>
Change-Id: Ic5456bc5a36f95186cdc6fe01ef1068b7124a5fc
This commit add parameters in the ptp-notification helm chart
for config file paths, holdover and frequency time interval values
for the GNSS, OS clock and overall sync monitors.
Test Plan:
PASS: Apply application with helm chart overrides.
Story: 2010056
Task: 46012
Signed-off-by: Teresa Ho <teresa.ho@windriver.com>
Change-Id: I7630c045ade2fb155657c19614508bcce020e90e
This commit adds support for tracking the overall time sync status of a
node by looking at the aggregated state of monitored time components and
reporting "Locked/Holdover/Freerun" accordingly. If all subcomponents
are Locked then the overall state reports Locked. If a component is
degraded, then this will cause the overall state to transition.
This functionality allows a consumer to subscribe to a single status
rather than having to handle a subscription for each individual
component.
Also included in this change are some logic fixes for GNSS, PTP and OS
Clock to handle cases where they were not transitioning properly. This
change also replaces the "new_event" variable value with a bool instead
of a string - the new_event var was not working properly previously and
was causing the status to be published even if nothing had changed. This
will reduce the number of updates being sent to clients.
Story: 2010056
Task: 45963
Change-Id: I41fd2bf202df8a9b7d3d1266f50e41a71df78273
Signed-off-by: Cole Walker <cole.walker@windriver.com>
This change fixes two issues found in the helm chart specification for
ptp-notification application:
1) Correct name of socket in the host when legacy PTP configuration is
found;
2) Avoid failure in the pod creation when no legacy PTP configuration is
found, since the original hostPath type "Socket" is required to
exist, which is not the case in that (valid) scenario. In this case,
the "type" field is reset which causes the path check to be dismissed
Test Plan:
PASS: Pod (containers) running with changed (fixed) ptp-notification tgz
Closes-Bug: 1981821
Signed-off-by: Douglas Henrique Koerich <douglashenrique.koerich@windriver.com>
Change-Id: I0efc1bdec525366ef09a87f1d0fc311cc5216656
Add the fluxcd app for ptp-notification to the debian build.
Test Cases:
PASS: Check deb install and application upload + apply on debian
PASS: Check application remove and delete on debian
Logs: https://paste.opendev.org/show/bVFc2ewiTos3FQ1kOAq0/
Story: 2009138
Task: 44663
Signed-off-by: Rei Oliveira <Reinildes.JoseMateusOliveira@windriver.com>
Change-Id: I4ba0340ac51a73d655b9cf1d8972d43534f5a07c
This commit switches ptp-notification to use the fluxcd app by
default and also preserves the armada app on the build for future
tests.
TEST PLAN
PASS Build iso and verify apps
PASS Upload
PASS Apply
PASS Verify resources [1] pod stuck at ContainerCreating due to ptp
misconfiguration on StarlingX, unrelated to the app or FluxCD)
PASS Remove
PASS Delete
Logs: https://paste.opendev.org/show/bZuqIQIdGAXOAAVO3jRl/
[1] On the 1st attempt to verify the resources created, we got the
ptp-ptp-notification pod stuck on ContainerCreating due to ptp
misconfiguration on StarlingX (unrelated to the app or FluxCD). After
troubleshooting the configuration, the pod got running OK and we used
the ptp-notification-demo-app to verify the protocol was acting as
expected.
2nd verification log: https://paste.opendev.org/show/bGDjZu6jrxw6lCdYQZNo/
Story: 2009138
Task: 45371
Signed-off-by: Thiago Brito <thiago.brito@windriver.com>
Change-Id: Ib4812f2def774a83c5838700006ee686b8d28198
Add new manifest files to the ptp-notification app to enable FluxCD support.
The new spec will now generate 2 rpms:
- the original one that contains the armada
version of the ptp-notification app
- a new one that contains the new FluxCD
version of ptp-notification app
Test Cases:
PASS: Verify that there are no changes to the armada rpm generated
PASS: Run the rpm build and verify that two packages are generated:
stx-ptp-notification-helm-<version>.tis.noarch.rpm and
stx-ptp-notification-helm-fluxcd-<version>.tis.noarch.rpm
PASS: Install the new package with kustomize and verify that ptp-notification
pod is deployed and running with success
PASS: Verify that both armada and fluxcd generated the same ptp-notification
application version
PASS: Deleting app.
Task: 44662
Story: 2009138
Change-Id: I20e6dcffb82ba8ed10b222459ac5fe37070d7493
The values added in change-id
Ibc1fc6c6342f873ea75c2e4015eb4c910b7010fd
work properly, but it was pointed out during additional
testing that it would be sensible to change the values to
better facilitate the transition from the old single-instance
ptp to the new multi-instance ptp.
This update changes the default values to reference the
legacy ptp naming scheme that users will encounter when migrating
their ptp configurations. This will mean that in some cases, users
will be saved from having to provided helm overrides for
ptp-notification.
Story: 2009130
Task: 44757
Signed-off-by: Cole Walker <cole.walker@windriver.com>
Change-Id: Iae55e409875c2ca4bd5b042a5da5617607edf407
This change adds support for the ptp-notification armada app to track
the clock status on a node operating as GM. This is required for nodes
running Westport Channel NICs using the GNSS module as the clock and
time of day source. This will require a rebuild of the
notificationservice container image.
The also fixes an issue where ptp-notification would no longer deploy
with multi-instance ptp because several of the paths that were being
mounted to the pods have been changed. The fix was to change these paths
to user-configurable variables which can be supplied to the notification
application as helm overrides. This change is only to the helm charts
and does not require an image build.
Testing:
PASS: Build and deploy stx-ptp-notification-helm with multi instance
ptp.
PASS: Build notificationservice container and deploy with helm charts,
validated that a GM node reported locked/holdover/freerun status
correctly.
Closes-Bug: 1961358
Story: 2009130
Task: 44700
Signed-off-by: Cole Walker <cole.walker@windriver.com>
Change-Id: Ibc1fc6c6342f873ea75c2e4015eb4c910b7010fd
