6:22 p.m.
I've been thinking about the tricky issue of RPM upgrades and how they
interact with the new networking stuff and don't think we've currently
got quite the optimal setup.
The current approach is that 'make install' puts a default.xml file
into /etc/libvirt/qemu/networks and also symlinks that file into the
autostart directory. So if someone builds from tar.gz and does make
install they'll get a default network config installed & turned on
out of the box. This is fine for tar.gz scenario.
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).
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 ?
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
9:48 p.m.
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.
Have you tried how rpm reacts to a %config(noreplace) for those files ?
I am not sure how it deals with file deletions, but for files changed by
the user, it properly creates the new file as .rpmnew (and some people
actually have scripts to help them reconcile the rpmnew files with their
changes, interactively, of course)
David
10:02 p.m.
On Tue, Mar 13, 2007 at 07:48:11PM -0700, David Lutterkort wrote:
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.
Have you tried how rpm reacts to a %config(noreplace) for those files ?
I am not sure how it deals with file deletions, but for files changed by
the user, it properly creates the new file as .rpmnew (and some people
actually have scripts to help them reconcile the rpmnew files with their
changes, interactively, of course)
The deletion of files is unfortunately the most important bit - and as
far as my testing has seen, no matter what you annotate with, if you
delete a file it will always get re-created upon upgrade :-(
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
4:23 a.m.
Daniel P. Berrange wrote:
On Tue, Mar 13, 2007 at 07:48:11PM -0700, David Lutterkort wrote:
> 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.
> Have you tried how rpm reacts to a %config(noreplace) for those files ?
> I am not sure how it deals with file deletions, but for files changed by
> the user, it properly creates the new file as .rpmnew (and some people
> actually have scripts to help them reconcile the rpmnew files with their
> changes, interactively, of course)
The deletion of files is unfortunately the most important bit - and as
far as my testing has seen, no matter what you annotate with, if you
delete a file it will always get re-created upon upgrade :-(
I can't find an example of default.xml in CVS, so I may be talking
through my hat, but some suggestions:
(1) Allow the default network to be disabled by editing the default.xml
file, eg:
<networks disabled='true'>
...
(2) Put a big comment at the top of the file saying:
<!-- to disable default network, rename this file to
default.xml.disabled -->
and then explicitly check for this in %post before trying to reinstall
the default.xml file.
Rich.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
"[Negative numbers] darken the very whole doctrines of the equations
and make dark of the things which are in their nature excessively
obvious and simple" (Francis Maseres FRS, mathematician, 1759)
6:58 a.m.
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.
7:48 a.m.
On Tue, Mar 20, 2007 at 11:58:55AM +0000, Mark McLoughlin wrote:
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.
Not being able to delete it also sucks & I don't think we should compromise
the impl just to workaround RPM issues.
> 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.
We do get the default network on upgrade the first time you upgrade from
a non network-enabled libvirt. So everyone upgrading from FC6 -> F7, for
example, will get it. We also stash a copy of the default network XML into
/usr/share/libvirt/networks. I plan to stuff a whole bunch more example
network configs in there too, illustrating how to setup various different
forwarding options, and IPv6 support, etc, because the default network XML
is very simple and not likely to be suitable for everyone, so they may
well wish to have an alternate default network - at least with different
IP address ranges.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
6460
days inactive
6467
days old
5 comments
4 participants
participants (4)
-
Daniel P. Berrange -
David Lutterkort -
Mark McLoughlin -
Richard W.M. Jones