Description of problem: While performing a vdsm update manually on RHEL-Host, rsyslog is the dependency any thing apart from this like "syslog-ng" cannot be used. # yum deplist vdsm > /tmp/dep # grep rsyslog /tmp/dep dependency: rsyslog provider: rsyslog.x86_64 4.6.2-2.el6 provider: rsyslog.x86_64 4.6.2-3.el6 provider: rsyslog.x86_64 4.6.2-3.el6_1.1 provider: rsyslog.x86_64 4.6.2-3.el6_1.2 provider: rsyslog.x86_64 4.6.2-3.el6_1.4 provider: rsyslog.x86_64 4.6.2-12.el6 provider: rsyslog.x86_64 5.8.10-2.el6 provider: rsyslog.x86_64 5.8.10-6.el6 provider: rsyslog.x86_64 5.8.10-7.el6_4 provider: rsyslog.x86_64 5.8.10-8.el6 ... Version-Release number of selected component (if applicable): RHEV-3.3 How reproducible: always Steps to Reproduce: 1. Put RHEL Hosts into maintenance mode and perform an update on it manually. 2. When syslog-ng is being used, rsyslog acts as an obstacle while updating vdsm. Actual results: vdsm does not update. Expected results: vdsm should not depend on rsyslog package to update.
# rpm -qR vdsm | grep syslog rsyslog
See http://gerrit.ovirt.org/13509 and bug 928861 on why we need syslog running. If we want to support syslog-ng, we can have a more complex "soft" dependency, where vdsm checks on startup whether one of the two is available. Anand, could you explain why syslog-ng is required? What happens if you --force rpm limitations away? Does Vdsm works and logs properly?
As requested on the users ML, here is my response why a hard dependency should not be necessary: a usecase for a different syslog is utilize existing log infrastructure which doesn't use rsyslog, perhaps? e.g. syslog-ng furthermore: vdsms logging is configured via /etc/vdsm/logger.conf and uses the python module logging: https://docs.python.org/2/library/logging.html this module is pretty cool, it allows you to redirect your logging basically to wherever you like, including syslog services or files, whatever. so why restrict this builtin feature by adding a hard dependency to a specific logging service? I know it's done because it's built on red hat linux where rsyslog is the default, and I don't want to say rsyslog is bad, it's just not used by everybody. As I understand there is work be done to port vdsm and engine to different distros like debian/ubuntu and gentoo. If you really want to port your software, keep it portable. This means in the first place don't introduce dependencies which aren't absolutely necessary. This one isn't really necessary. I can report to you that e.g. syslog-ng handles vdsm logs well. ;) HTH PS: We circumvented this dependency afaik by keeping rsyslog installed but disabled the start of the service. But my colleague could provide more details on the exact steps that where taken.
I inspected https://bugzilla.redhat.com/show_bug.cgi?id=928861 which is, according to you, the reason for the dependency. But it is not, quoting from this BZ: https://bugzilla.redhat.com/show_bug.cgi?id=928861#c8: syslog listens on /dev/log socket and logger tries to open it, if syslog runs with corrupted configuration this socket won't be created. I propose a patch that check this file before starting vdsm process. First: It's correct that "syslog" listens on this device, but syslog doesn't need to be rsyslog. So you could just check for /dev/log and not for a specific syslog implementation. Second: You _can_ configure logger.conf to not use syslog (a.k.a. /dev/log) at all, thus avoiding this complete dependency. For the sake of portability this dep should get removed or softened. Thanks.
I am not suggesting to use `rpm --force` on a production environment. I'm only soliciting for help in testing whether syslog-ng can somehow transparently replace syslogd, when it comes to Vdsm.
Dan, we do check for /dev/log during start (http://gerrit.ovirt.org/#/c/13547/), instead of having the requirement in the spec, we can specify in syslog_available output that user must install rsyslog\other alternative, to allow vdsm syslog reports before starting vdsmd up. is it acceptable and enough?
Sounds good to me.
Verified in vdsm-4.16.1-0.gita4d9abf.el6.x86_64
As this is a very minor change, is there any change to backport it to 3.4.z?
I don't mind backporting http://gerrit.ovirt.org/26941. Sven, please clone this bug to 3.4.4.
Clone created at: https://bugzilla.redhat.com/show_bug.cgi?id=1143923 thanks for your effort Dan! It's much appreciated!
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-0159.html