[ovs-dev] [PATCH 4 of 5] Clear stale configuration keys on boot
blp at nicira.com
Thu Oct 1 09:58:36 PDT 2009
Ian Campbell <Ian.Campbell at eu.citrix.com> writes:
> On Wed, 2009-09-30 at 21:20 +0100, Ben Pfaff wrote:
>> Ian Campbell <ian.campbell at citrix.com> writes:
>> > diff -r 655d69fcd68a -r aa941ec68c03 xenserver/etc_init.d_vswitch
>> > --- a/xenserver/etc_init.d_vswitch Wed Sep 30 11:17:45 2009 +0100
>> > +++ b/xenserver/etc_init.d_vswitch Wed Sep 30 11:38:22 2009 +0100
>> > @@ -264,6 +264,12 @@
>> > if [ ! -e "$VSWITCHD_CONF" ]; then
>> > warning "$VSWITCHD_CONF does not exist"
>> > action "Creating empty $VSWITCHD_CONF" touch "$VSWITCHD_CONF"
>> > + else
>> > + /usr/bin/ovs-cfg-mod '-vANY:console:emer' -F "$VSWITCHD_CONF" \
>> > + '--del-match=bridge.*' \
>> > + '--del-match=port.*' \
>> > + '--del-match=bonding.*' \
>> > + '--del-match=iface.*'
>> > fi
>> It makes a lot of sense to do this (frankly we ought to have been
>> doing this all along) but doing it here will break "service
>> vswitch restart", which normally works OK, at least for me.
> I hadn't considered that.
>> need some way to only delete all that on first boot, but not
>> later. I wonder if there's a good way to tell. We could just
>> avoid it when "restart" is used, but then anyone who does
>> "service vswitch stop; service vswitch stop" gets screwed, which
>> is not good either.
>> Is there a good way to tell that this is the first time we're
>> being run? Maybe we can create a file in /var/run, since that
>> gets cleaned at boot time.
> Yes, I think that would work and I can't think of much else. I think it
> would be possible to tell if the script is being run by init vs manually
> (by hand or via the service command) but I suspect that would break
> changing runlevels.
OK, I pushed a patch that uses /var/run/vswitch.booted. Maybe
this can be improved.
> Is it worth considering splitting the persistent and ephemeral
> configuration into separate files (or just providing an "include" type
> directive)? Then it would be possible to put the ephemeral stuff itself
> under /var/run.
> Will the config database changes effect this in any way?
You are definitely right that it makes sense to split persistent
and ephemeral state. For the config database we should be able
to designate tables or columns as ephemeral, so that should solve
the problem after the db is available.
More information about the dev