Description of problem: At the moment vdsm makes sure we are installing ntp rpm. However we are not doing anything with the service, its not running and disabled. We should either configure it, or not install it at all. Version-Release number of selected component (if applicable): vdsm-4.19.6-1.el7ev.x86_64 How reproducible: Steps to Reproduce: 1. Deploy host check ntpd status Actual results: ntpd is installed, not running and disabled Expected results: ntpd should be running and configured or rpm should not be installed Additional info: I agree with having user docs to configure ntpd, however when he can configure it he can even install the package. If its recommended leave it in docs on user, if its necessery for stuff like migration configure it with some defaults.
Also consider that el7 has also chrony, which some users might prefer.
Doing simple git blame on the requirement gives you a link to the patch that explains why the developer added it - http://gerrit.ovirt.org/903 (quite long time ago) BZ#619360 enable and start ntpd Vdsm needs to keep host time in sync, or else guest time would lap if guest is started on a different host. Make sure ntpd is running. If this is not relevant anymore, please tell why and involve guest guys that will verify that.. if it is relevant please update this bug Adding Vinzenz, maybe he can share if guest agent still requires ntpd to be up.. probably yes
after host deploy, ntp rpm is installed, however vdsm does not track the service - configure start or enable ntpd service
vdsm should be able to be run and installed from rpm installation as well... not only after ovirt host deploy process. and if vdsmd service is depended on having ntpd running, we need to have it installed before starting vdsmd service
(In reply to Yaniv Bronhaim from comment #4) > vdsm should be able to be run and installed from rpm installation as well... > not only after ovirt host deploy process. and if vdsmd service is depended > on having ntpd running, we need to have it installed before starting vdsmd > service I don't think the problem is installation - how do we ensure it's configured? I think we have some event complaining if there is a time difference somewhere?
As far as I remember we don't configure it ourselves. Not sure about an event. I recall we have one on the engine level. Not that says ntp isn't configured, but one that says the time isn't synced. Martin?
Also what is the status of ntp on engine? Do we force to be running or leave it upon user?
Administrators themselves should configure time synchronization for all of their hosts, this should be part of basic networking configuration, we don't know which NTP servers can be used (no idea if a host has access to Internet NTP servers or customer has its own NTP server). So I don't see a reason why VDSM depends on ntp package if we don't configure it (not to mention that there are other packages providing NTP functionality). Also engine checks time drift of the hosts against engine time and if host time drift is higher than allow value defined in HostTimeDriftInSec engine-config option, an alert is raised. So I'd remove VDSM dependency on NTP and leave NTP configuratio completely on administrators.
but current vdsm dependency, as I said in comment #2, was added for the guest.. Adding Vinzenz again.. maybe he can share if guest agent still requires ntpd
This says 'guest' not guest agent. That's quite simple why the host needs to stay synchronized with the NTP servers. Imagine you migrate a VM from host A to host B and they have a time difference of 15 minutes. The time would suddenly jump after the migration. Anyway there's no reason for the dependency. If a customer/user has a problem with this, they need to ensure that their system is configured accordingly. Node needs to ensure that on their own as well. +1 for dropping ntp dependency - That's a normal must have on a system IMHO
(In reply to Oved Ourfali from comment #6) > As far as I remember we don't configure it ourselves. It seems like we did enable ntpd at the time. I guess this was lost, perhaps when we moved to ovirt-host-deploy in 3.2, and no-one noticed so far, essentially claiming comment 8 (which is also what I thought before I saw that bug/patch). It's still an open question whether we need it today and why. I guess we still do. Whether this should be in our scope is a different question - we also need name resolution and leave that to the user to handle (using /etc/hosts, manual dns management, or e.g. foreman). Also noting that even if it's not a requirement of the product, it's extremely more convenient to debug complex problems, involving several different machines, if their clocks are synced, and log files easily match.
for some reason I can't add lsvaty and vfeenstr to review the patch - so add youself and please review
(In reply to Martin Perina from comment #8) > Administrators themselves should configure time synchronization for all of > their hosts, this should be part of basic networking configuration, we don't > know which NTP servers can be used (no idea if a host has access to Internet > NTP servers or customer has its own NTP server). So I don't see a reason why > VDSM depends on ntp package if we don't configure it (not to mention that > there are other packages providing NTP functionality). because we want the NTP to be set up as easily as possible. We didn't want to go as far as managing its configuration (decision ~4 years ago), but we want to pick up dhcp defaults and have config files around so it is a simple step for hte admin. Time sync is critical > > Also engine checks time drift of the hosts against engine time and if host > time drift is higher than allow value defined in HostTimeDriftInSec > engine-config option, an alert is raised. yes, set to 5 mins which is a bit too much by default > So I'd remove VDSM dependency on NTP and leave NTP configuratio completely > on administrators. Big -1, I do not see why are you removing it
Vdsmd used to be depend on it so when it starts also ntpd used to start. But as it is today, ntpd will be installed but nothing will start or manage it. maybe the bug should be that its not part of vdsmd.service requirements ?
that's ok, we should probably restore the functionality. But even if we don't, keeping it there half-ready is still better than completely removing it - that would be a step back. We do not want to manage the whole NTP configuration, there are plenty of system-level tools around, but there is also the automagic when the service is on and DHCP configured correctly you get it working without even thinking about it. That covers a lot of users. See bug 1266824 - chronyd is the replacement and comes out enabled by default - I think if we replace the requirement on RHEL7 from ntpd to chronyd we will get our automagic back.
OK, if we can get automatic NTP configuration from DHCP by default, then it makes sense to have dependency or ntp/chrony (and the we should probably also enable and start ntp service by default). Thanks Michal for explaining the original reason, you were the only who remembered ...
it doesn't make much sense. if vdsmd does not start ntpd for more than 5 versions back (I don't see it in ovirt-3.3 branch as well) and nothing enabled the service automatically as well, the requirement that was there for quite long (as comment #2 shows) is totally a leftover. Im not sure what will be the consensuses for starting it now with vdsmd on any system. it might lead to regressions Adding to vdsmd.service ntpd dependency should be an rfe for the version which requires some advance testings iiuc, don't you agree?
Nir, I would like to hear your opinion as maintainer for this request: 1. adding rpm requirement to install a package that enable itself by default and count on its auto configuration 2. start external service with vdsmd.service for network time sync without configuring it - which we never did over centos7 but we used to do over centos6 which according to comment #13 is a regression 3. this rfe also requires change in engine side to decrease the warning threshold afaiu
(In reply to Yaniv Bronhaim from comment #19) > Nir, I would like to hear your opinion as maintainer for this request: > 1. adding rpm requirement to install a package that enable itself by default > and count on its auto configuration > 2. start external service with vdsmd.service for network time sync without > configuring it - which we never did over centos7 but we used to do over > centos6 which according to comment #13 is a regression So, if automatic NTP configuration via DHCP works fine (assuming you have NTP configuration inside DHCP), then it makes sense to me to enable ntpd service by default. But we need to check if it doesn't break vdsm startup if host has static IP or DHCP doesn't provide valid NTP server. > 3. this rfe also requires change in engine side to decrease the warning > threshold afaiu I'd handle that in separate RFE ...
Found the commit that removed it - https://gerrit.ovirt.org/#/c/11291/ Seems like still chronyd is enabled by default.. Michal, is that enough? do you still think vdsm should also depend on it before running?
Probably we can close this request - chronyd is enabled by default for awhile, so unless an admin stopped it by purpose, it should run without any interventions in parallel to vdsm. vdsm should not depend on chronyd, it can lead to inconsistency changes in vdsmd.service behavior so I don't think we should add such dependency now.
Again, I think it's ok when we say we do not manage the actual configuration and one ca decide to reconfigure/disable chronyd and we do not check for that. That's ok. But we still should do the basic - pull the package in in case of installation on minimal RHEL where it is not present by default(I suppose at least - is that true?)
Dan, based on that that you removed this dependency in first place [1] (but left the rpm dependency), please give your opinion about Michal requests [1] https://gerrit.ovirt.org/#/c/11291/
Vdsm's service requires time-sync.target, which might be either ntpd or chronyd. vdsm.rpm should pull one of them, to make sure they exist on ovirt-node image. Since ntpd is considered old-fashioned these days, I don't mind switching vdsm.rpm to chrony.
Verified: # repoquery --requires --resolve vdsm | grep chrony chrony-0:2.1.1-4.el7_3.x86_64 # repoquery --requires --resolve vdsm | grep ntpd # repoquery --resolve vdsm vdsm-0:4.19.12-1.el7ev.x86_64