Description of problem: NFV cRAN/vRAN are looking for better time synchronization and distribution in general as alternative for NTP; with hardware timestamping support on host, PTP can achieve clock accuracy in the sub-microsecond range, making it suitable for measurement, control systems. meanwhile, with latest enhancement of kvm virtual PTP driver(bz1419783) in RHEL-7.4, guest OS could acquire the same level accuracy by utilizing the gettime method provided by virtual PTP driver which invokes a hypercall to get the host clock. To make use of these high precision timing drivers in openstack, several changes are needed in openstack components, for example to identify hardware ptp capable nodes, to install and deploy package/services of linuxptp in compute nodes with tripleo, to expose virtual ptp capability info to VM so that chronyd can be configured to read from host ptp time source, etc. fault/performance management and other "service assurance" related processes can also benefit from more accurate time of PTP. for example, fault/error events will include timestamps placed on the associated event messages, retrieved by detectors with the purpose of accurately identifying the time that the event occurred; service assurance processes depend on the time-series data, which is collected in the various entities in the distributed system. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: end to end use case description: https://docs.google.com/document/d/1XzZV0qPa6wTS_SVUI13C2-lHhya04bU8P-SApkxb_r4/edit
This bugzilla has been removed from the release and needs to be reviewed and Triaged for another Target Release.
Since director deploys NTP by default, enabling ptp services means you have to consider the co-exist of NTP and PTP, whether feeds PTP source to NTP or vice versa. the latter one may not happen if you're not going to deploy a grandmaster of PTP on one of the deployed nodes. there is also a method provided by linuxptp for leveraging NTP and PTP, that is to use timemaster which is a program (it can be configured as a service) that uses ptp4l and phc2sys in combination with chronyd or ntpd to synchronize the system clock to NTP and PTP time sources. you might also want to consider the possible impact on service or components that reply on NTP.
upstream bp & spec review: https://blueprints.launchpad.net/tripleo/+spec/tripleo-ptp https://review.openstack.org/#/c/483227/
spec got merged: https://review.openstack.org/#/c/483227/
all upstream patches merged. Addressed by: https://review.openstack.org/483227 Tripleo PTP (Precision Time Protocol) support Addressed by: https://review.openstack.org/491317 Add PTP composable service Addressed by: https://review.openstack.org/491324 Add PTP service Addressed by: https://review.openstack.org/526630 add puppet-ptp into image
What all needs to be present in OSP 13 to satisfy this RFE?
(In reply to Jon Schlueter from comment #13) > What all needs to be present in OSP 13 to satisfy this RFE? Below patches are needed to use PTP in osp 13: PTP composable service in tripleo-heat-templates: https://review.openstack.org/491317 PTP service in puppet-tripleo: https://review.openstack.org/491324 puppet-ptp in tripleo-puppet-elements: https://review.openstack.org/526630 do we need to create separate bz for each of the component and link them here?
is puppet-ptp packaged in RDO at all at this point for Queens cycle?
moving back to ON_DEV until puppet-ptp is packaged in RDO
Does that mean that one can choose choose either PTP or NTP for overcloud configuration? What about support of PTP and choice between PTP/NTP for undercloud? Since this BZ is targeted for OSP14 what is the plan to backport it to OSP13?
As a QA, I would like to know how to test this.
(In reply to Sanjay Upadhyay from comment #31) > As a QA, I would like to know how to test this. In order to configure and use PTP, environment yaml file[1] for ptp shall be added in the openstack deployment cmd, there are three parameters exposed in the yaml file: 1) PtpInterface: 'eth0' 'eth0' is the network interface name which supports hardware PTP; 2) PtpSlaveMode: 1 configure PTP to slave mode which is the only supported mode, shall not be changed. 3) PtpMessageTransport: 'UDPv4' configure the protocol to use for ptp message transportation. If ptp interface is added to an ovs bridge, it shall be configured to 'L2' (layer 2) mode since there is no associated IP address on the physical interface which means 'UDPv4' mode can not work. Note: when PTP physical interface works in slave mode, a remote PTP master shall be configured and reachable via the PTP interface on slave node. [1]: https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ptp.yaml
(In reply to arkady kanevsky from comment #24) > Does that mean that one can choose choose either PTP or NTP for overcloud > configuration? > What about support of PTP and choice between PTP/NTP for undercloud? > > Since this BZ is targeted for OSP14 what is the plan to backport it to OSP13? Regarding the first question, yes, once PTP is configured, NTP will be disabled by default in current implementation. For example, in the ptp yaml file[1], it sets NTP configuration to None: OS::TripleO::Services::Ntp: OS::Heat::None There is no support for PTP configuration in undercloud. For question 2, Franck may be able to help. setting needinfo. [1]: https://github.com/openstack/tripleo-heat-templates/blob/master/environments/services/ptp.yaml
Hi, Only compute nodes have PTP NICs (SolarFlare) at my clients. We are trying to deploy OSP13 . Is there a way to use NTP for controllers and ceph and PTP for compute ? Thx
Chris, can you comment what does it mean? Which versions of RHEL, RHCoreOS, RHOSP and RHOCP support PTP?
This BZ is about RHOSP only, and this BZ was tracking an upstream implementation that is done and that we now track in https://bugzilla.redhat.com/show_bug.cgi?id=1825895 FYI the code tracked in this BZ is shipped with RHOSP13 already (supported as community support for now since RHOSP13).