[libvirt] [PATCH] libvirt: move default nwfilters to datadir.

Daniel P. Berrange berrange at redhat.com
Wed Mar 18 10:37:29 UTC 2015


On Wed, Mar 18, 2015 at 10:09:53AM +0000, Dimitri John Ledkov wrote:
> On 17 March 2015 at 19:04, Daniel P. Berrange <berrange at redhat.com> wrote:
> > On Tue, Mar 17, 2015 at 06:52:31PM +0000, Dimitri John Ledkov wrote:
> >> libvirt runs correctly without any configuration files, as sensible
> >> defaults are used throughout. This commit introduces a layer for
> >> nwfilter configuration. This means that default filters are shipped in
> >> /usr/share/libvirt/nwfilter/ directory, which can be overridden by
> >> things in /etc/libvirt/nwfilter. This is similar to configuration
> >> splits as observed in udev, systemd, XDG Base Directory Specification
> >> and so on. This will make a distinction and make it obvious if any of
> >> the nwfilters are modified by the administrator.
> >
> > I think this is really not something we want to do. Having multiple
> > directories to store configs in is going to have more fallout than
> > your patch shows. For a start this breaks the ability to delete these
> > filters, since the deletion code assumes they're in a particular
> > directory. Now if the same named filter is present in both locations
> > the delete API does not know which to delete.
> >
> 
> OK, I'll check that. So far I did simplistic testing and
> overwrote/remove filters by placing a filter without any rules but
> with the same name attribute in /etc and nwfilter-list / dumpxml still
> worked correctly. I will check the behaviour of define/undefine/edit
> as well.
> 
> > If we were doing this again today, we'd simply not ever install  any
> > filters by default. Leave it entirely upto the app/admin using libvirt
> > to decide which filters are present. To that end we already split the
> > filters off into a separate optional RPM, so that users can skip their
> > installation.  So if people want to modify these, we should really
> > just be recommending that they not install this RPM in the first place
> >
> 
> Well... OpenStack software Nova component references the stock filters
> in their base configuration, e.g. no-mac-spoofing, no-ip-spoofing,
> no-arp-spoofing, allow-dhcp-server and so on. Thus these filters
> whilst example content, ended up being an API (removing them will
> break OpenStack Nova component). Hence the desire to move them away to
> /usr, as these shouldn't be modified, or at least that one can revert
> to stock versions of these.

I think i'd be better if Nova just defined its own set of rules for
everything it needs rather than relying on what happens to be prsent,
or not present, by default.

> Would you be at all open to any other semantics with stock filters
> moved out of /etc? E.g. have filters loaded from /usr to not be
> modifiable / marked read-only from the API, or only allowed to be
> referenced using filterref? (thus making these filters essentially
> builtin/well-known aliases for typical filtering pieces).

No, that would be a semantic change in behaviour of the API which would
potentially break applications

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|




More information about the libvir-list mailing list