Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-32733

PTP operator should report status in the 'status' section of the 'PtpConfig' object

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Won't Do
    • Icon: Minor Minor
    • None
    • 4.14
    • Networking / ptp
    • None
    • Low
    • No
    • False
    • Hide

      None

      Show
      None
    • 8/14: won't do

      Description of problem:

      There is no way to observe the state of a PTP configuration in the ptp configuration object

      Version-Release number of selected component (if applicable):

      All

      How reproducible:

      100%

      Steps to Reproduce:

          1. Configure PTP by creating a PtpConfig.ptp.openshift.io object with a valid 'spec' section
          2. Try to ascertain whether the PTP config is correct and if PTP is synchronized by checking the PtpConfig object 'status' section via 'oc describe'
          

      Actual results:

      The PtpConfig object does not report any status or events. The only way to check whether PTP is synchronized is by using 'oc exec', and running manual debug commands in the linuxptp-daemon-container container.

      Expected results:

      The PtpConfig object should provide status including:
      - A list of objects, one for node running ptp
      - Each of these node-level objects should contain an object for each linux interface configured for PTP in the PtpConfig object, and maybe general status like whether ptp4l and phy2sys are running
      - Each interface object should include:
        - The name of the linux interface
        - The last observed PTP state (listening / synchronized / slave / timeSender / master / etc)
        - The last observed time offset in ns
        - For slave/timeReciever ports, the ID, clock class, and timesource of the grandmaster to which it is synced
        - For master/timeSender ports, the ID, clock class, and timesource of the grandmaster it is providing to others
      
      Note: This is just a suggestion of what I think would be useful, domain experts may have other ideas or better ways of organizing the data; for example, any global state could be in the top-level 'status' section and not an interface-specific list.

      Additional info:

      Here's an example output that would look nice:
      
      [kni@registry ~]$ oc get -n openshift-ptp ptpconfig du-ptp-slave -o yaml
      apiVersion: ptp.openshift.io/v1
      kind: PtpConfig
      metadata:
        creationTimestamp: "2024-04-23T05:59:56Z"
        generation: 1
        name: du-ptp-slave
        namespace: openshift-ptp
        resourceVersion: "15341"
        uid: 3b1a1565-4080-4f03-9ade-bd671bb209d1
      spec:
        profile:
        - interface: ens3f1
          name: slave
          phc2sysOpts: -a -r -n 24
          ptp4lConf: |
            [global]
            #
            # Default Data Set
            #
            twoStepFlag 1
            slaveOnly 1
            ...
            timeSource 0xA0
          ptp4lOpts: -2 -s --summary_interval -4
          ptpSchedulingPolicy: SCHED_FIFO
          ptpSchedulingPriority: 10
          ptpSettings:
            logReduce: "true"
        recommend:
        - match:
          - nodeLabel: node-role.kubernetes.io/master
          priority: 4
          profile: slave
      status:
        - node: cnfdg16
          ptp4lState: running
          phc2sysState: running
          interfaces:
            - name: ens3f1
              state: synchronized
              offset: 47
              clockSource:
                - id: "00:17:47:ff:fe:70:15:bd"
                  class: 6
                  timeSource: 0xa0

            aputtur@redhat.com Aneesh Puttur
            jramsay1@redhat.com Jim Ramsay
            Gowrishankar Rajaiyan Gowrishankar Rajaiyan
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: