|
|
Post by sunitha on Apr 7, 2022 5:28:18 GMT
The current NetworkProtocol schema has "NTPServers" property which lists the current active NTP servers set on the system. There is no way to differentiate between the DHCP provided NTP servers and the servers set by the user statically. This property should be defined similar to the "NameServers" and "StaticNameServers" where it can be clearly identifiable as which IP is set statically by the user. Another change needed is: NTPServers should also be made as properties of EthernetInterface resource. So that each ethernet interface, which may connect to different subnet of the system, can set different NTP servers. Please refer a systemd discussion on the same at github.com/systemd/systemd/issues/22384 |
|
|
|
Post by mraineri on Apr 7, 2022 20:51:13 GMT
Thanks for pointing this out to us. I think conceptually most of us believed that NTP server configuration was more of a global thing for a manager rather than it being interface specific. We'll need to review these pointers and discuss this internally.
|
|
|
|
Post by sunitha on Apr 8, 2022 9:34:00 GMT
Sure. Thank you !
I think we can still retain that global setting as per the systemd discussion. But we need the NTP servers at ethernet interface level as well - so that the systems which need two interfaces at two different subnets can do the required settings
|
|
|
|
Post by sunitha on Apr 8, 2022 9:55:18 GMT
@edtanous please share your views as well
|
|
|
|
Post by edtanous on Apr 8, 2022 16:48:31 GMT
From my perspective (in this case as OpenBMC bmcweb maintainer), CRUD semantics need to be followed for PATCH operations to the NTPServers property, which is fairly complex, if not impossible by having a single parameter. Having DHCP-set NTPServers complicates this, because it seems important to separate out the "DHCP set NTPServers" from the "User set NTPServers" in the tree, with the DHCP-set NTP servers property being both interface specific, and probably read-only.
With that said, I don't have a ton of background on the use cases for this, so I'm open to other options.
|
|
|
|
Post by mraineri on Apr 11, 2022 18:17:54 GMT
One thing that has come up is trying to understand the need of controlling this on an interface by interface perspective. From my understanding, while it's possible to be that granular with the settings for NTP servers, is there a real practical need to support this? My impression is most users like to control this for the entirety of the manager rather than going through each of the interfaces, but if there really is a good usage for being specific to each of the interfaces, I'd like to understand that first.
|
|
|
|
Post by sunitha on Apr 12, 2022 14:16:36 GMT
One thing that has come up is trying to understand the need of controlling this on an interface by interface perspective. From my understanding, while it's possible to be that granular with the settings for NTP servers, is there a real practical need to support this? My impression is most users like to control this for the entirety of the manager rather than going through each of the interfaces, but if there really is a good usage for being specific to each of the interfaces, I'd like to understand that first. This is what i had received from the systemd experts. ------------------------------------------------------------------- About the question why NTP or DNS servers assigned by networkd is per-link config. Because each network interface may be connected to different network. For example, if the host is a router, then one interface is connected to upstream (WAN), and another is to downstream (LAN). In such case, the NTP or DNS provided through WAN interface cannot be connected through the LAN interface, and vice versa. And if the WAN interface becomes down, then timesyncd or resolved should and can handle that the DNS or NTP servers assigned to the WAN interface cannot be accessed if these settings are per-link. If these servers are assigned globally, these daemons cannot do like that. Anyway, this is the design of timesyncd, resolved, and networkd. And we cannot change that. And I do not think there is no good reason to change that. Closing. ------------------------------------------------------------------ |
|
|
|
Post by sunitha on May 17, 2022 14:02:06 GMT
|
|
|
|
Post by jautor on May 17, 2022 20:23:59 GMT
We interpreted the last message with "Closing" to mean that there was no change needed. Is that not accurate? |
|
|
|
Post by mraineri on May 17, 2022 23:44:10 GMT
We interpreted the last message with "Closing" to mean that there was no change needed. Is that not accurate? That was a quote from the systemd folks as to why they have it on each interface (not a closure of the subject from a Redfish perspective). |
|
