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

Ben Pfaff blp at nicira.com
Mon Oct 5 17:15:33 UTC 2009


Ian Campbell <Ian.Campbell at citrix.com> writes:

> ovs-vsctl did not exist when this code was originally written, but it
> provides exactly what is needed to get rid of those separate state
> files.

Thank you, this is very nice.

> The vif hotplug script diff is against the xs5.7 branch but I think is
> applicable to master and/or citrix with just context changes.

It can't go to "citrix" unless we add ovs-vsctl to that branch,
so I resolved the conflicts on "master" and pushed it there.

I'm going to merge "citrix" into "master", then "master" into
xs5.7 soon.

> 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 think that ovs-vsctl should probably support multiple
operations in one go.  I have two notions about how that might
work.  One, there could be a separator argument between commands,
say "," or "--".  Two, ovs-vsctl could accept commands from
stdin, one per line, if "-" was given as its argument, or perhaps
from a command file with, say, "-f <filename>".  I think I like
the latter better.

Some commands have output.  We would have to decide how to
separate the output from the various commands.  For commands that
have exactly one line of output, I guess there's no problem.  I
guess we could redefine the other commands to have
space-separated, single-line output instead of the current
new-line-separated, multi-line output, if that seems like an OK
approach to you.

I don't know exactly how to deal with it if one command succeeds
and another fails within a single run.  I guess we would probably
want the whole thing to be transactional: everything succeeds or
everything fails.

Comments welcome, I haven't even started implementing any of
this.




More information about the dev mailing list