Public bug reported: Correct system time is important for certificate validation and log correlation, and drifting time can cause issues with distributed consensus mechanisms (like the one used by the ceph-mon daemon). Most ready-made cloud-images will try to connect to one or multiple public NTP servers to synchronize their system time. This requires internet access, limits precision, and can suffer from rate-limiting if multiple instances use the same floating IP to connect to the same NTP server.
Cloud providers can help users to avoid this by offering a local NTP server. In OpenStack this is currently only possible through a provider network that instances have to connect to. Some cloud providers are offering local NTP servers to instances directly via link-local addresses: - GCP via metadata.google.internal (169.254.169.254) [1] - AWS via 169.254.169.123 and fd00:ec2::123 [2] It might be useful to support something like that in Neutron as well, similar to the injection of the metadata service or DHCP agents into subnets. The feature could be implemented in a way that also allows other services, such as DNS, to be forwarded into subnets. I looked at a number of cloud images, and all that include (S)NTP clients (and are not targeted to a specific hyperscaler) will also use NTP servers provided via DHCP, so that seems like a good method of informing instances of a local NTP server. (I have not yet tested DHCPv6 support, though) [1] https://cloud.google.com/compute/docs/instances/configure-ntp [2] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configure-ec2-ntp.html ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2084894 Title: [RFE] Support injection of local NTP servers into subnets Status in neutron: New Bug description: Correct system time is important for certificate validation and log correlation, and drifting time can cause issues with distributed consensus mechanisms (like the one used by the ceph-mon daemon). Most ready-made cloud-images will try to connect to one or multiple public NTP servers to synchronize their system time. This requires internet access, limits precision, and can suffer from rate-limiting if multiple instances use the same floating IP to connect to the same NTP server. Cloud providers can help users to avoid this by offering a local NTP server. In OpenStack this is currently only possible through a provider network that instances have to connect to. Some cloud providers are offering local NTP servers to instances directly via link-local addresses: - GCP via metadata.google.internal (169.254.169.254) [1] - AWS via 169.254.169.123 and fd00:ec2::123 [2] It might be useful to support something like that in Neutron as well, similar to the injection of the metadata service or DHCP agents into subnets. The feature could be implemented in a way that also allows other services, such as DNS, to be forwarded into subnets. I looked at a number of cloud images, and all that include (S)NTP clients (and are not targeted to a specific hyperscaler) will also use NTP servers provided via DHCP, so that seems like a good method of informing instances of a local NTP server. (I have not yet tested DHCPv6 support, though) [1] https://cloud.google.com/compute/docs/instances/configure-ntp [2] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configure-ec2-ntp.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2084894/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
