Across numerous industries, accurate timing is a frequent requirement. Most commonly, this is enabled through Network Time Protocol (NTP), which will generally provide millisecond-level accuracy. When NTP isn’t good enough, users can use Precision Time Protocol (PTP), which can guarantee accuracy to within 100 nanoseconds. The most common open source implementation of this protocol is through the linuxptp package.
The Red Hat OpenShift PTP operator is intended to provide support for using and configuring the linuxptp package on Red Hat OpenShift, providing enhanced-precision timing using PTP. This level of precision is often tightly coupled to the specific hardware that a system is using, with various hardware-dependent configurations needed. An example of this would be setting hardware configuration pins on a network interface card. Providing this level of timing accuracy is often a requirement in industries such as telecommunications (telco), finance, and industrial automation.
Given the tight dependencies on hardware partners to ensure appropriate levels of performance for precision timing, Red Hat has moved primary development of the PTP operator available to a broader community, better facilitating an upstream-first development model.
Building a broader community
Previously, all development was under the OpenShift organization, solely managed by Red Hat, and not receptive to external contributors. All hardware-specific functionality was delivered through plugins in the daemon, developed by Red Hat Engineering using the documentation of that hardware as a reference. Partner testing did not necessarily use the operator, but rather tested at the lower layers, often on bare metal. Without partner testing utilizing the full software stack, as customers do, and without their close alignment during plugin development, there was more room for errors and additional complications in development.
For better collaboration with both hardware vendors and software partners, Red Hat has moved primary development of the PTP operator outside of OpenShift into a broader community. This move intends to make contributing to the PTP operator more straightforward for external parties, especially in the context of hardware-specific code. It will also give them an environment to properly test their hardware with a full software stack, closer to how customers will be using it, rather than waiting for Red Hat to test it.
Selecting a new home
Once Red Hat had decided to move the PTP operator to a community-development model, the next step was to find where this community would live. When looking for a new home, Red Hat’s requirements included finding somewhere both with a networking focus and a cloud-native context. With these considerations in mind, the k8snetworkplumbing was the most natural fit, and their endorsement was a strong factor in this decision.
After reaching the initial, informal agreement with the k8snetworkplumbing community, Red Hatters that previously maintained the OpenShift PTP operator became members of the k8snetworkplumbing community to get the project proposal formally approved upstream. Once approved, Red Hat began pushing the code upstream, making the necessary changes for it to run upstream and be in conformance with open source design principles. Finally, the Red Hat team needed to ensure that the process for accepting contributions in the upstream project was clearly defined, as explained in the contributing guide. This helps enable anyone interested in supporting the development of the PTP operator to get involved.
New workflow
Now that the PTP operator has moved to a community-oriented development model, almost all code will be delivered to the upstream projects first, specifically at the 2 repositories: ptp-operator and linuxptp-daemon. However, changes to the ContainerFiles, which are using Red Hat Enterprise Linux (RHEL) base images rather than CentOS Stream base images, are the exception. They are only relevant downstream, so they are not delivered to the upstream repository.
All development is delivered at those upstream repositories, and then Red Hat merges it to the downstream main branches for the respective OpenShift repositories.
Using this downstream main branch allows Red Hat Engineering to provide images to the Red Hat Quality Engineering team to continue testing. Those images would be built upon a RHEL base image, rather than using the upstream ContainerFiles, which use CentOS Stream as the base image.
Red Hat quality
While development is upstream first, backports of bug fixes and features to prior releases are still expected to be frequently required, as is driven by the business needs of our partners. This significantly limited the scope of changes Red Hat could make to the PTP operator. In particular, Red Hat was unable to consolidate the two repositories into one because of backport costs.
When it comes to quality, it’s important to consider both upstream and downstream quality. Moving upstream will neither compromise the upstream nor the downstream quality.
When it comes to upstream quality, the purpose is to ensure that there is a consistently deployable product from the upstream repository. This requires a limited subset of unit testing and linting to ensure that nothing is broken, and to stop from adding overhead to the in-depth testing downstream. This should allow higher development velocity upstream.When it comes to downstream quality, the testing is the same as before, except with end-to-end testing running when merging upstream to downstream, rather than merging individual features into downstream. Quality engineering testing will remain on downstream builds, specifically those built on Red Hat base images.
Regarding security issues, Red Hat Engineering plans to resolve those issues both upstream and downstream quickly, and backport fixes where appropriate.
Going forward
Now that this is in a community-based project, the priority is to grow the community to include collaborators from other companies, in particular hardware partners.
If you’re interested in getting involved, please reach out to ptp-dev@redhat.com, or join our upstream community meeting at ptp community agenda.
