Commit 19c671dd authored by adietmue's avatar adietmue
Browse files

Reduce potential timing issues.

parent ff5d0b07
......@@ -320,12 +320,13 @@ Concretely, the following happens first:
1. The network is built (`./cli.sh build`).
2. Requirements are installed (`./cli.sh install-requirements`).
3. The P4 programs are compiled and the P4 switches are started, along with static rules (`./cli.sh start-switches`).
4. Configuration scripts are executed (`./cli.sh configure-nodes`).
> The first time you build the network it will take few minutes because the script pulls several docker images, after it should be faster.
Afterwards, the following things happen *at the same time*:
Right after the configuration commands have been sent, the following happens *at the same time*:
- Traffic and failure generation is started (`./cli.sh run-scenario`).
- Configuration scripts are executed (`./cli.sh configure-nodes`).
- The controller for P4 switches is started (`./cli.sh run-controller`).
As described above, traffic and failures will not begin immediately, so your routers and controller will have a few seconds to converge to their final state.
......
......@@ -237,14 +237,16 @@ function pipeline
install-requirements
start-switches
# The configure node calls to docker exec can block the traffic generator,
# so we have to do it before to avoid timing issues.
configure-nodes
# Controller and router config is loaded at the same time as the scenario.
# They have a few seconds to converge before traffic actually starts.
run $@ & runpid=$!
controller $@ & controllerpid=$!
configure-nodes & configpid=$!
wait $runpid || return $error
wait $configpid || return $usererror
# The controller might loop -> kill it if it's still running.
if ! kill $controllerpid > /dev/null 2>&1; then
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment