Re: [libvirt] [PATCH] libvirt: move default nwfilters to datadir.
On 17 March 2015 at 19:04, Daniel P. Berrange <berrange(a)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.
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).
--
Regards,
Dimitri.
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.