On Fri, Jul 14, 2023 at 08:44:04AM -0700, Andrea Bolognani wrote: > On Fri, Jul 14, 2023 at 04:25:48PM +0100, Daniel P. Berrangé wrote: > > On Fri, Jul 14, 2023 at 08:13:11AM -0700, Andrea Bolognani wrote: > > > RHEL 8 got libvirt 6.0.0, which comes with socket activation support, > > > back in 2020 with RHEL 8.3. Based on our support policy we only > > > consider the latest point release a valid target anyway, but in this > > > case we should absolutely be in the clear. > > > > I'm still not convinced that makes this obsolete though. > > > > We introduced it but that's not ensuring every deployment is actually > > using it. We spent some time explaining to people how to stick with > > non-activation scenarios if they weren't ready to change things like > > ansible admin scripts from earlier RHEL-8.x > > > > Of course with any distro version at all, people could have turned > > off activation, but with RHEL-9 I'd be more comfortable saying it > > is unlikely because activation was the default from day 1, unlike > > 8. > > Just to make sure we're on the same page. The code I'm deleting looks > like this: > > # See if user has previously modified their install to > # tell libvirtd to use --listen > grep -E '^LIBVIRTD_ARGS=.*--listen' /etc/sysconfig/libvirtd 1>/dev/null 2>&1 > if test $? = 0 > then > # Then lets keep honouring --listen and *not* use > # systemd socket activation, because switching things > # might confuse mgmt tool like puppet/ansible that > # expect the old style libvirtd > /bin/systemctl mask \ > libvirtd.socket \ > libvirtd-ro.socket \ > libvirtd-admin.socket \ > libvirtd-tls.socket \ > libvirtd-tcp.socket >/dev/null 2>&1 || : > /bin/systemctl try-restart libvirtd.service >/dev/null 2>&1 || : > else > # Old libvirtd owns the sockets and will delete them on > # shutdown. Can't use a try-restart as libvirtd will simply > # own the sockets again when it comes back up. Thus we must > # do this particular ordering, so that we get libvirtd > # running with socket activation in use > /bin/systemctl stop libvirtd.service >/dev/null 2>&1 || : > /bin/systemctl try-restart \ > libvirtd.socket \ > libvirtd-ro.socket \ > libvirtd-admin.socket >/dev/null 2>&1 || : > /bin/systemctl start libvirtd.service >/dev/null 2>&1 || : > fi > > The 'else' branch deals with switching libvirtd < 5.6.0 to use proper > socket activation. All of our targets come with much newer versions > of libvirt at this point, so either they already had socket > activation enabled out of the box or they must have been switched > over by now. Which makes at least this branch obsolete, agreed? > > The 'if' branch deals with the scenario in which --listen has been > configured, which is a non-default configuration that we don't want > to mess with. Fair enough. But, for that configuration to work at > all, the various sockets must have already been masked, either by > some deploy-time automation or by this scriptlet running at some > point between when libvirt < 5.6.0 was installed and now. And since > we're not touching socket during upgrades from the regular > %libvirt_daemon_perform_restart macro anyway, we can't really mess > this stuff up. Ok, so its only a problem if they are still running < 5.6.0 when they upgrade, which is probably an unreasonably upgrade gap to be credibly concerned about. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
