yahoo-eng-team team mailing list archive

[Konrad Gube <2084894@xxxxxxxxxxxxxxxxxx>]

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