This is more complicated than it should be. We are also relying on
the fact that waitOutput should eat extra prompts most of the time.
Still not perfect - it's hard to get this exactly right, and we
should try to make it easier!
Fixes#589
It appears that read() has been blocking for some time,
so for now it makes sense to change the documentation to
match the functionality!
It's not entirely clear if monitor() expects this functionality.
However, with the current blocking read() semantics, it should
definitely return (and not call read()) on a poll timeout.
So, we now return the poll() result from waitReadable() (which
should have done this already probably) and check it. In the
fullness of time, we still need to revisit the whole I/O API
and make sure that it is consistent, sane, correctly documented,
and used correctly in the examples.
See #588 for more comments.
I'm not sure whether we really need to turn off ip_forward before
flushing iptables, but it might possibly be useful to avoid certain
unexpected behavior.
The justification for this is that 1) the options are
already documented in the API documentation and 2) the
class names are fairly self-explanatory, so adding short
descriptions doesn't add much.
In the future, however, we could add a short description
by simply using the first line or sentence of the docstring;
note that docstrings would have to be canonicalized, which
they aren't now.
When I changed the switch implementations to call super().stop(),
I neglected to include a Switch.stop() method which didn't call
terminate(). This broke switch s1 stop and s1.stop().
Fixes#497
specialClass is an analog of functools.partial but for classes.
We can now use it instead of partial() in mn, so that Mininet
can introspect on the actual base class.
Fixes#488
This was causing controlnet.py to not clean up its interfaces, since
those interfaces were linked from the controller to the switch
rather than vice-versa!!
deleteIntfs already will only delete interfaces whose names match
our name, which should usually prevent us from accidentally deleting
a hardware interface from the root namespace!
Since we already disable job notification with +m, it doesn't
make sense to set it in the original invocation!
It's also annoying if all of the host commands end up overwriting
your regular bash_history!!
Batch startup support for OVS
Currently, every ovs-vsctl command requires reading the entire OVS
configuration database. This means that its performance gets linearly
slower as more switches and ports are added. To mitigate this, we
batch multiple configuration operations into individual, long,
ovs-vsctl commands.
This patch set makes a couple of other notable changes, including
setting printPid=False by default (avoids using mnexec unnecessarily)
and running certain commands using errRun rather than quietRun.
Additionally we no longer look for leftover links in the root
namespace, so code relying on that functionality may have to change
slightly (as in controlnet.py and sshd.py for example.) It also adds
cluster support to mn -c.
The performance result is that mn --topo linear,200 --test none now
completes in 60 seconds rather than 95 seconds (on my laptop) without
the patch (vs. 101 seconds in 2.2.0).
This is still slower than I would like - we should be able to make
some additional improvements.
If you try to use the low-level API, you are probably
not going to call batchStartup()! So, we set batch=False
by default. This means that buildFromTopo() needs to set
it to True, so we add a bit of irritatingly complex machinery
to allow this to happen. The good fallout of this is that
now customConstructor() returns a real subclass, not simply
a constructor function! We also detect errors where people
are incorrectly attempting to give parameters to a lambda
function - since none of our lambdas accept parameters!!
Note that this is a bit like functools.partial for classes -
it would be nice if functools had a true subclassing function.
Note that we are changing the interface of batchStartup/Shutdown
slightly so that the method can choose not to start some of the
switches. We might wish to refine this a bit...
This should rarely happen - in the usual case, either the
links will be shut down by Mininet.stop(), or the interfaces
will be deleted by node.stop( deleteIntfs=True ), or the
links or interfaces will be explicitly deleted or stopped
using the low-level API.
Cases that are relying on links being automatically deleted
in cleanup() will potentially find that they are now no longer
deleted, but these cases should be rare.
Bob Lantz