Description of problem: Application timing pod needs to perform read operations on uds sockets for PTP sync. This is currently not exposed and this request is to support uds socket via a host mount
Is there a reason they cannot take the approach outlined in https://issues.redhat.com/browse/KNIDEPLOY-4125 of performing the following from a privileged container? [root@ocp4-rwn-1 ~]# ID=$(crictl ps --label io.kubernetes.container.name=linuxptp-daemon-container -o json | jq -r '.containers[0].id') [root@ocp4-rwn-1 ~]# PID=$(crictl inspect $ID | jq -r '.info.pid') [root@ocp4-rwn-1 ~]# nsenter -at $PID pmc -u -f /var/run/ptp4l.0.config -i ens2f0 'GET CURRENT_DATA_SET' sending: GET CURRENT_DATA_SET 644c36.fffe.129f80-0 seq 0 RESPONSE MANAGEMENT CURRENT_DATA_SET stepsRemoved 2 offsetFromMaster 0.0 meanPathDelay 395.0 [root@ocp4-rwn-1 ~]#
Timing application Pod is generic one and runs on multiple kubernetes platforms. Our aim is not to add any specific for a type of deployment as it would break for other customers. Using uds socket is most common approach followed and wanted them to be exposed.
Random notes that may be useful to future readers: https://www.mankier.com/8/pmc mentions a command line switch: -s uds-address Specifies the address of the server's UNIX domain socket. The default is /var/run/ptp4l. https://www.mankier.com/8/ptp4l indicates there is a matching config option on the server: uds_address Specifies the address of the UNIX domain socket for receiving local management messages. The default is /var/run/ptp4l. If/how these options can be used to resolve this bug is as yet unclear
Can you clarify this last statement: > Our aim is not to add any specific for a type of deployment as it would break for other customers. Specifically, which customers are being referred to? Non-telco OCP customers, or other telco customers running this timing application Pod? Also, which deployment are you referring to? The PTP operator Pod, or the timing application Pod?
Timing application pod needs to access uds socket. Current PTP operator pod has uds socket which is inside its container namespace. This is the requirement we have put forward. Let me know if the requirement is not clear.
(In reply to sksingh from comment #5) > Timing application pod needs to access uds socket. Current PTP operator pod > has uds socket which is inside its container namespace. > > This is the requirement we have put forward. Let me know if the requirement > is not clear. Sorry, that doesn't clarify the statement made in comment #2
Validated on Server Version: 4.7.0-fc.2 Kubernetes Version: v1.20.0+394a5a3 Operator Image: registry.redhat.io/openshift4/ose-ptp@sha256:dd6ba55d34ef585a0a9dcae2633a0d085e2a195edba92c1d4a1806220157f69d When PTP synced new files appear under /var/run/ptp/ on client's node sh-4.4# ls -l /var/run/ptp/ total 4 srw-rw----. 1 root root 0 Feb 16 14:53 phc2sys.1983019 -rw-r--r--. 1 root root 1896 Feb 16 14:53 ptp4l.0.config srw-rw----. 1 root root 0 Feb 16 14:53 ptp4l.0.socket drwxr-xr-x. 2 root root 40 Feb 9 13:16 secrets I move this BZ to verified
Verified
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Container Platform 4.7.0 security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:5633