libvirt.spec.in | 274 ++++++++++++++++++++++++++++++++---------------- 1 file changed, 183 insertions(+), 91 deletions(-)
This is a V1 of my previous RFC to decompose the libvirt-daemon package https://listman.redhat.com/archives/libvir-list/2022-November/235924.html The end goal is to remove the libvirt-dameon dependency on the various libvirt-daemon-driver-foo subpackages, allowing installation of a modular daemon configuration without the traditional monolithic libvirtd. Change from V1: - Patches1-3 handled separate from this series since they are unrelated - virtlockd, virtlogd, and virtproxyd are moved to their own subpackages - lockd plugin moved to its own subpackage - virt-admin, virt-host-validate, and others moved to new subpackage TODO: The libvirt-daemon package still contains the following files, which likely need to move somewhere since they are needed by the modular daemons too. %{_unitdir}/virt-guest-shutdown.target I thought of moving this to the libs package, but that would be a change for installations with only libvirt-client. AFAICT, it's used by libvirt-guests and the qemu and lxc drivers. %config(noreplace) %{_sysconfdir}/sasl2/libvirt.conf Another file related to remote access. Should it go to libvirt-libs? %ghost %dir %{_rundir}/libvirt/ %ghost %dir %{_rundir}/libvirt/common/ %dir %attr(0755, root, root) %{_localstatedir}/lib/libvirt/ %dir %attr(0711, root, root) %{_localstatedir}/lib/libvirt/images/ %dir %attr(0711, root, root) %{_localstatedir}/lib/libvirt/filesystems/ %dir %attr(0711, root, root) %{_localstatedir}/lib/libvirt/boot/ %dir %attr(0711, root, root) %{_localstatedir}/cache/libvirt/ %dir %attr(0755, root, root) %{_libdir}/libvirt/ %dir %attr(0755, root, root) %{_libdir}/libvirt/connection-driver/ These files and directories are needed by the modular daemons as well, right? Where should they go? libvirt-daemon-<hypervisor> or libvirt-daemon-driver-<hypervisor>? %{_datadir}/polkit-1/actions/org.libvirt.unix.policy %{_datadir}/polkit-1/actions/org.libvirt.api.policy %{_datadir}/polkit-1/rules.d/50-libvirt.rules More files related to access. libvirt-libs? Jim Fehlig (7): spec: Move virtlockd to a new subpackage libvirt-daemon-lock spec: Move virtlogd to a new subpackage libvirt-daemon-log spec: Move virtproxyd to a new subpackage libvirt-daemon-proxy spec: Move lockd plugin to a new subpackage libvirt-daemon-plugin-lockd spec: Move common files to a new subpackage libvirt-daemon-client spec: Remove libvirt-daemon dependecy from drivers spec: Remove libvirt-daemon dependency from hypervisor subpackages libvirt.spec.in | 274 ++++++++++++++++++++++++++++++++---------------- 1 file changed, 183 insertions(+), 91 deletions(-) -- 2.38.1
On Fri, Dec 02, 2022 at 05:17:31PM -0700, Jim Fehlig wrote: > This is a V1 of my previous RFC to decompose the libvirt-daemon package > > https://listman.redhat.com/archives/libvir-list/2022-November/235924.html > > The end goal is to remove the libvirt-dameon dependency on the various > libvirt-daemon-driver-foo subpackages, allowing installation of a > modular daemon configuration without the traditional monolithic libvirtd. snip > libvirt.spec.in | 274 ++++++++++++++++++++++++++++++++---------------- > 1 file changed, 183 insertions(+), 91 deletions(-) Could you also update docs/daemons.rst to mention the new sub-RPMS that are getting created. 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 :|
On 12/13/22 02:31, Daniel P. Berrangé wrote: > On Fri, Dec 02, 2022 at 05:17:31PM -0700, Jim Fehlig wrote: >> This is a V1 of my previous RFC to decompose the libvirt-daemon package >> >> https://listman.redhat.com/archives/libvir-list/2022-November/235924.html >> >> The end goal is to remove the libvirt-dameon dependency on the various >> libvirt-daemon-driver-foo subpackages, allowing installation of a >> modular daemon configuration without the traditional monolithic libvirtd. > > snip > >> libvirt.spec.in | 274 ++++++++++++++++++++++++++++++++---------------- >> 1 file changed, 183 insertions(+), 91 deletions(-) > > Could you also update docs/daemons.rst to mention the new sub-RPMS > that are getting created. Currently that file contains no mention of RPM, package, subpackage, etc. But poking around I suppose you mean docs/kbase/rpm-deployment.rst. I'll update it in V2. Regards, Jim
On Tue, Dec 13, 2022 at 04:14:33PM -0700, Jim Fehlig wrote: > On 12/13/22 02:31, Daniel P. Berrangé wrote: > > On Fri, Dec 02, 2022 at 05:17:31PM -0700, Jim Fehlig wrote: > > > This is a V1 of my previous RFC to decompose the libvirt-daemon package > > > > > > https://listman.redhat.com/archives/libvir-list/2022-November/235924.html > > > > > > The end goal is to remove the libvirt-dameon dependency on the various > > > libvirt-daemon-driver-foo subpackages, allowing installation of a > > > modular daemon configuration without the traditional monolithic libvirtd. > > > > snip > > > > > libvirt.spec.in | 274 ++++++++++++++++++++++++++++++++---------------- > > > 1 file changed, 183 insertions(+), 91 deletions(-) > > > > Could you also update docs/daemons.rst to mention the new sub-RPMS > > that are getting created. > > Currently that file contains no mention of RPM, package, subpackage, etc. > But poking around I suppose you mean docs/kbase/rpm-deployment.rst. I'll > update it in V2. Sigh, yes, I mean rpm-deployment.rst ! 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 :|
On Fri, Dec 02, 2022 at 05:17:31PM -0700, Jim Fehlig wrote: > The libvirt-daemon package still contains the following files, which likely > need to move somewhere since they are needed by the modular daemons too. > > %{_unitdir}/virt-guest-shutdown.target > I thought of moving this to the libs package, but that would be a change > for installations with only libvirt-client. AFAICT, it's used by > libvirt-guests and the qemu and lxc drivers. IIUC this basically acts as a synchronization point during shutdown: no guest will be torn down before it has been reached, and the daemon will not be shut down either. On a default install, this is where libvirt-guests.service would have a chance to perform the ON_SHUTDOWN action, but the local admin or management application can replace that with their own custom implementation. > %config(noreplace) %{_sysconfdir}/sasl2/libvirt.conf > Another file related to remote access. Should it go to libvirt-libs? This configures the remote side of the connection. > %ghost %dir %{_rundir}/libvirt/ > %ghost %dir %{_rundir}/libvirt/common/ > %dir %attr(0755, root, root) %{_localstatedir}/lib/libvirt/ > %dir %attr(0711, root, root) %{_localstatedir}/lib/libvirt/images/ > %dir %attr(0711, root, root) %{_localstatedir}/lib/libvirt/filesystems/ > %dir %attr(0711, root, root) %{_localstatedir}/lib/libvirt/boot/ > %dir %attr(0711, root, root) %{_localstatedir}/cache/libvirt/ > %dir %attr(0755, root, root) %{_libdir}/libvirt/ > %dir %attr(0755, root, root) %{_libdir}/libvirt/connection-driver/ > These files and directories are needed by the modular daemons as well, > right? Where should they go? libvirt-daemon-<hypervisor> or > libvirt-daemon-driver-<hypervisor>? Server-side, and not specific to any hypervisor. > %{_datadir}/polkit-1/actions/org.libvirt.unix.policy > %{_datadir}/polkit-1/actions/org.libvirt.api.policy > %{_datadir}/polkit-1/rules.d/50-libvirt.rules > More files related to access. libvirt-libs? These are for access to a local daemon, not remote access. And again it's the server configuring what clients should be allowed to connect to it. Assuming I've gotten all of the above right :) then it seems to me that all these files need to go in one of the server-side packages. I think we should just have a libvirt-daemon-common package that includes what you currently have put into the libvirt-daemon-client package plus these files, and have all hypervisor drivers depend on it directly. Which would basically keep things as they are: right now installing libvirt-daemon-driver-qemu results in these files begin present because they're part of the libvirt-daemon package, and after this change the same would be true except for the monolithic daemon not coming along for the ride. -- Andrea Bolognani / Red Hat / Virtualization
On 12/11/22 10:46, Andrea Bolognani wrote: > On Fri, Dec 02, 2022 at 05:17:31PM -0700, Jim Fehlig wrote: >> The libvirt-daemon package still contains the following files, which likely >> need to move somewhere since they are needed by the modular daemons too. >> >> %{_unitdir}/virt-guest-shutdown.target >> I thought of moving this to the libs package, but that would be a change >> for installations with only libvirt-client. AFAICT, it's used by >> libvirt-guests and the qemu and lxc drivers. > > IIUC this basically acts as a synchronization point during shutdown: > no guest will be torn down before it has been reached, and the daemon > will not be shut down either. On a default install, this is where > libvirt-guests.service would have a chance to perform the ON_SHUTDOWN > action, but the local admin or management application can replace > that with their own custom implementation. > >> %config(noreplace) %{_sysconfdir}/sasl2/libvirt.conf >> Another file related to remote access. Should it go to libvirt-libs? > > This configures the remote side of the connection. > >> %ghost %dir %{_rundir}/libvirt/ >> %ghost %dir %{_rundir}/libvirt/common/ >> %dir %attr(0755, root, root) %{_localstatedir}/lib/libvirt/ >> %dir %attr(0711, root, root) %{_localstatedir}/lib/libvirt/images/ >> %dir %attr(0711, root, root) %{_localstatedir}/lib/libvirt/filesystems/ >> %dir %attr(0711, root, root) %{_localstatedir}/lib/libvirt/boot/ >> %dir %attr(0711, root, root) %{_localstatedir}/cache/libvirt/ >> %dir %attr(0755, root, root) %{_libdir}/libvirt/ >> %dir %attr(0755, root, root) %{_libdir}/libvirt/connection-driver/ >> These files and directories are needed by the modular daemons as well, >> right? Where should they go? libvirt-daemon-<hypervisor> or >> libvirt-daemon-driver-<hypervisor>? > > Server-side, and not specific to any hypervisor. > >> %{_datadir}/polkit-1/actions/org.libvirt.unix.policy >> %{_datadir}/polkit-1/actions/org.libvirt.api.policy >> %{_datadir}/polkit-1/rules.d/50-libvirt.rules >> More files related to access. libvirt-libs? > > These are for access to a local daemon, not remote access. And again > it's the server configuring what clients should be allowed to connect > to it. > > > Assuming I've gotten all of the above right :) then it seems to me > that all these files need to go in one of the server-side packages. > > I think we should just have a libvirt-daemon-common package that > includes what you currently have put into the libvirt-daemon-client > package plus these files, and have all hypervisor drivers depend on > it directly. Taking a cue from the storage driver, I called it libvirt-daemon-core (patches 4-6) in the original RFC https://listman.redhat.com/archives/libvir-list/2022-November/235924.html But I'm fine with libvirt-daemon-common too :-). I'll change it in V2 while addressing the other comments. Regards, Jim
On Mon, Dec 12, 2022 at 03:19:31PM -0700, Jim Fehlig wrote: > On 12/11/22 10:46, Andrea Bolognani wrote: > > I think we should just have a libvirt-daemon-common package that > > includes what you currently have put into the libvirt-daemon-client > > package plus these files, and have all hypervisor drivers depend on > > it directly. > > Taking a cue from the storage driver, I called it libvirt-daemon-core > (patches 4-6) in the original RFC > > https://listman.redhat.com/archives/libvir-list/2022-November/235924.html > > But I'm fine with libvirt-daemon-common too :-). I'll change it in V2 while > addressing the other comments. I wasn't unable to find a document that contains a formal policy on this, but my understanding is that foo-core is a stripped-down version of foo that only contains the very basic functionality, while foo-common is stuff needed by foo and doesn't do anything useful on its own. Based on this reading, libvirt-daemon-driver-storage-core and libvirt-daemon-common are the appropriate names for the respective packages. Anyone with actual RPM packaging experience, please call me out if I'm spouting nonsense :) -- Andrea Bolognani / Red Hat / Virtualization
On Tue, Dec 13, 2022 at 01:15:26AM -0800, Andrea Bolognani wrote: > On Mon, Dec 12, 2022 at 03:19:31PM -0700, Jim Fehlig wrote: > > On 12/11/22 10:46, Andrea Bolognani wrote: > > > I think we should just have a libvirt-daemon-common package that > > > includes what you currently have put into the libvirt-daemon-client > > > package plus these files, and have all hypervisor drivers depend on > > > it directly. > > > > Taking a cue from the storage driver, I called it libvirt-daemon-core > > (patches 4-6) in the original RFC > > > > https://listman.redhat.com/archives/libvir-list/2022-November/235924.html > > > > But I'm fine with libvirt-daemon-common too :-). I'll change it in V2 while > > addressing the other comments. > > I wasn't unable to find a document that contains a formal policy on > this, but my understanding is that foo-core is a stripped-down > version of foo that only contains the very basic functionality, while > foo-common is stuff needed by foo and doesn't do anything useful on > its own. > > Based on this reading, libvirt-daemon-driver-storage-core and > libvirt-daemon-common are the appropriate names for the respective > packages. > > Anyone with actual RPM packaging experience, please call me out if > I'm spouting nonsense :) Once you go beyond -devel, -docs and -libs, sub-RPM naming is almost[1] entirely arbitrary, and at the discretion of the package maintainer With regards, Daniel [1] caveat: programming language specific guidelines may apply -- |: 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 :|
© 2016 - 2024 Red Hat, Inc.