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.