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

Ian Campbell Ian.Campbell at eu.citrix.com
Tue Oct 6 09:33:36 UTC 2009


On Mon, 2009-10-05 at 18:15 +0100, Ben Pfaff wrote:
> Ian Campbell <Ian.Campbell at citrix.com> writes:
> > 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.

No problem, I didn't realise ovs-vsctl was master only.

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

Thanks.

> > 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.

I'm not sure which is easier to script. I guess it comes down to:
        ovs-vsctl CMD1 args1 -- CMD2 args2
vs
        ovs-vsctl -f - <<EOF
        CMD1 args1
        CMD2 args2
        EOF
(I don't think creating a temporary file and using -f on it is terribly
useful in this context but I guess little precanned snippets are a
possibility)

For the later constructing "CMD1 args\nCMD2 args" in shell could involve
some tricky quoting (not exactly rocket science, but still). So perhaps
it is worth allowing ';' as well as '\n' as a separator. At which point
the two forms become almost equivalent in both usage and, I suspect,
implementation:
        ovs-vsctl "CMD1 args1; CMD2 args2"
and
        ovs-vsctl -f - <<EOF
        CMD1 args1;
        CMD2 args2;
        EOF
so why not support both?

It might be worth supporting "--" in its common usage of separating
options from the rest of the command line?

> 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.

If we change the output format then I might/probably need to redo some
of my patches to xapi and/or XenRT. It's not a huge deal at this stage
but I'd like to be sure we were moving towards a stable interface.

Are there use cases where having multiple commands with output is
useful? I guess the answers would be atomic and therefore self
consistent which could be useful. I'm just wondering if we could
restrict it to multiple "state modifying" commands (or "at most one with
output")? It's kind of an artificial limitation but it might simplify
things?

How about '\0' separated? Since this is only likely to be used from
scripts might that be acceptable? Alternatively blank line separated
since all existing commands currently output one or more non-blank
lines.

> 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.

Yes, that sounds like the sanest approach.

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





More information about the dev mailing list