[libvirt] [PATCH 17/41] remote: refactor how list of systemd unit files is built

Daniel P. Berrangé berrange at redhat.com
Tue Jul 30 08:36:48 UTC 2019


On Mon, Jul 29, 2019 at 07:14:36PM +0000, Jim Fehlig wrote:
> On 7/29/19 8:18 AM, Andrea Bolognani wrote:
> > On Mon, 2019-07-29 at 13:17 +0100, Daniel P. Berrangé wrote:
> >> On Fri, Jul 26, 2019 at 08:01:52PM +0200, Andrea Bolognani wrote:
> >>> Again IIUC there's nothing really stopping us from generating
> >>> virtqemud*.service from libvirtd*.service.in, or at least from
> >>> a common virtd*.service.in, since eg. virtqemud.service.in and
> >>> virtlxcd.service.in are basically identical - it's just that you
> >>> haven't unified the generation rules yet.
> >>
> >> I'm was not anticipating sharing the service.in file, as many of
> >> the parameters will be driver specific.
> > 
> > It doesn't look to me like there's much more that's driver-specific
> > in the .service files than there is in the .socket files, and we're
> > generating the latter from a single template.
> 
> I have a downstream patch that adds
> 
> After=xencommons.service
> Conflicts=xendomains.service
> 
> to libvirtd.service.in. IMO the patch needs to be improved before pushing 
> upstream, e.g. conditionally adding those lines at build time when the xen 
> driver is selected. With driver-specific service files we can trivially add 
> those to virtxend.service.

Sure, go ahead & send that for libvirtd.service.in Meanwhile, I'll add them
to virtxend.sevice in my patch series right now.

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 :|




More information about the libvir-list mailing list