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

On 17 March 2015 at 19:04, Daniel P. Berrange <berrange(a)redhat.com&gt; 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.

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).