[ovs-dev] xenserver: use ovs-vsctl for VIF VLAN configuration instead of /var/lib/openvswitch/br-*

[Ian Campbell]

On Tue, 2009-10-06 at 17:35 +0100, Ben Pfaff wrote: 
> Ian Campbell <Ian.Campbell at eu.citrix.com> writes:
> 
> > I was thinking of using ovs-vsctl exclusively for configuration
> > modifications from the vif hotplug script but that would need a
> > mechanism to pass the additional vif details to ovs-vsctl add-port as
> > well as perhaps making the bridge optional to del-port. The other option
> > would be to use the --no-reload option and split the config mods into
> > two parts, but I don't like that idea much.
> 
> I forgot to respond to part of this before, about adding
> additional vif details.  I guess by this you mean the details
> that were previously dumped out by the "dump-vif-details"
> script.

Yes, that's what I meant.

>   I'm not sure that I have a clean solution for this
> particular problem.  If this part required an extra call to
> something else (ovs-cfg-mod I suppose) do you judge that it would
> still be valuable to add support for multiple operations in a
> single ovs-vsctl run?

I guess not. The only part of the current implementation which ovs-vsctl
could currently replace is the add-port equivalent bit so there would
only be a single operation. (It would still abstract the VLAN handling
stuff away nicely though, so that aspect might still be worthwhile).

ov-vsctl could have a mode where it prints the ovs-cfg-mod options
necessary to implement the given operations, instead of actually
performing them, but that seem pretty yucky to me and potentially error
prone if there are multiple operations with overlapping effects etc.

If add-port took a variable number of additional parameters of the form
X=Y which turned into port.$PORT.X=Y I think that would work. I'm not
sure how generically applicable that sort of CLI interface would be,
especially if you wanted to add iface.THING at the same time too (my
understanding of the distinction between port and iface is fuzzy at best
so perhaps that makes no sense anyway).

One slight concern I have with using ovs-vsctl from the vif script is
that the current ovf-cfg-mod calls in the vif script are not precisely
equivalent to the add/del-port ovs-vsctl operations. Most importantly
the ovs-cfg-mod parameters used on remove don't require a bridge name
while ovs-vsctl del-port does, this is significant because the bridge
name isn't easily available at the point where the hotunplug event
happens. Less importantly the ovs-cfg-mod parameters used for adding a
port include a flush of any identically named port from all other rules
while add-port would fail if there was an existing port, I think this
would indicate an earlier failure so am not really inclined to worry too
much.

I've also just realised that ovs-vsctl doesn't log the configuration
changes to syslog in the same way that ovs-cfg-mod can, that's pretty
handy from a debugging point of view. I think I might even consider it
worth sticking with ovs-cfg-mod for that very reason.

Ian.