On Mon, Feb 27, 2017 at 04:21:26PM +0100, José Luis Millán wrote: > On Fri, Feb 24, 2017 at 6:59 PM, Ben Pfaff <b...@ovn.org> wrote: > > > On Fri, Feb 24, 2017 at 01:10:23PM +0100, José Luis Millán wrote: > > > I am developing a simple utility tool that maintains connections with a > > > list of switches and adds and removes flows on them. > > > > > > It's been called 'ovs-proactivecontroller' and it is inspired by > > > 'ovs-testcontroller' utilitly, with the difference that the first does > > not > > > listen for connections since it is only intended to be used proactively. > > > > > > A new kind of switch has been created; 'passive_switch' (pswitch), > > > analogous to the existing 'learning_switch' (lswitch), which represents a > > > passive switch. > > > > > > The utility is a daemon which exposes a RPC interface via 'unixctl' > > server > > > with the following self explanatory API : > > > > > > - add_switch > > > - del_switch > > > - add_flow > > > - del_flows > > > > > > It also accepts as startup options a file name with a list of switches as > > > well as a file name with a list of flows. In case these options are > > > provided, the daemon connects to the given switches at startup and > > installs > > > the given flows upon connection. > > > > > > The aim of the utility is spreading the given flows on each switch. > > > > To me, this sounds a lot like ovs-testcontroller with the --with-flows > > option, with the added unixctl API. Did you consider refining > > ovs-testcontroller to support the unixctl API? It would be easy to > > accept those kinds of changes. > > > > I definitely agree. > > Let me please comment a couple of points. > > - switches would be added and removed based on the unixctl API as well as > via the current command line active connection methods (ssl:ip[:port], > tcp:ip[:port], > unix:file) > - ovs-testcontroller would not terminate when no more connections are > available. > > On the other hand, in lswitch_handshake (learning-switch.c) for OPF > versions greater than 13, a flow is being installed so the switch sends > packets to the controller by default. This is not a desirable behaviour for > the proactive controller. How can this cleanly made? Maybe providing a > utility option --proactive that translates into a lswitch property which is > checked before deciding whether to install such flow or not?
I think that would be a reasonable solution. I guess that command-line options can be added to give ovs-testcontroller the features that you want. I'd be in favor of such support, if you want to provide a patch. _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss