[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] RPM upgrades interaction with default networking



On Tue, 2007-03-13 at 23:22 +0000, Daniel P. Berrange wrote:

> When we build an RPM we also include the default.xml file in the 
> /etc/libvirt/qemu/networks directory, as well as the autostart symlink.
> So anyone installing the libvirt RPM gets the default network, whether
> they're doing an upgrade or fresh install.  This is reasonable for the
> new install, or the first time you upgrade to a new neworking-enabled
> libvirt. If you subsequently delete the default network, or turn off
> autostarting, then along comes the next libvirt RPM update and autostart
> gets turned back on, and/or the default network recreated. This will be
> considered to be rather unpleasant by many people because no matter
> what they do, they will always be given a virbr0, a dnsmasq process
> and a bunch of extra iptables rules whether they want them or not.
> 
> So I think we need to figure out a way to deploy a default network out
> of the box, but at the same time ensure that if the turn it off / delete
> it, upgrades won't re-introduce it.  Ideally if someone upgrades from
> FC6 -> FC7 they will also get the default network created (once only).

	TBH, it points me back to having the autostart flag in the XML. We
could make it impossible to delete the default network, but make it
possible to not autostart it.

> One way we can address this is to put the default.xml into the docs
> directory /usr/share/doc/libvirt-X.Y.Z (or perhaps stuff is into a dir
> like /usr/share/libvirt instead) and then have a RPM %post script which
> copies it into /etc/libvirt/qemu/networks. If we make the %post script
> conditional on '$1 == 1' then it will only be run for completely new
> libvirt installs. This doesn't address the upgrade question though -
> so someone updating from FC6 -> FC7 won't get the default network. Perhaps
> we shouldn't worry about them ?

	Not getting the default network on upgrade sucks, IMHO, but we've kind
of worked ourselves into a corner on this one.

Cheers,
Mark.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]