On Fri, Mar 09, 2018 at 10:54:01AM +0800, Xiao Liang wrote:
> Add ovs-ofproxy to enable tools like ovs-ofctl to work with non-OVS
> switches which don't support controller-initiated connection.
> The proxy listens for switches connection, opens a unix socket on behalf of
> each switch.
>
> Example:
> Start proxy
> $ ovs-ofproxy -O OpenFlow13 ptcp:6653
> After switch is connected, use ovs-ofctl:
> $ ovs-ofctl -O Openflow13 show unix:/var/run/openvswitch/tcp:...
> (see log of proxy for the socket path)
>
> Signed-off-by: Xiao Liang <shaw.l...@gmail.com>
I suggest adding some tests. If you do some work, you might be able to
get the existing testsuite to use ovs-ofproxy for all of its existing
ovs-ofctl calls, and thereby get some decent coverage. For example:
* Make ovs-ofproxy able to take an active connection method as
its argument (yes, that's a bit silly but bear with me). I
didn't check, maybe it already supports this.
* Make ovs-ofproxy able to run a subprocess.
* Use an appropriate shell function to substitute for ovs-ofctl.
It would need to parse options, etc., to pass the right -O to
ovs-ofproxy and get the right connection method, but short of
that this is the idea:
ovs-ofctl() {
remote=$1; shift
ovs-ofproxy "$remote" --listen punix:$$.sock --run ovs-ofctl $$.sock "$@"
}
Another way would be to make ovs-ofctl able to fork a ovs-ofproxy
subprocess internally (either literally fork/exec or just fork or
pthread_create() and then use ovs-ofproxy as a library) if you give it a
passive connection method. That actually seems simpler.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
