Build #3,539

FreeRangeRouting Protocol Suite

Build: #3539 was successful Changes by David Lamparter

Build result summary

Details

Completed
Duration
136 minutes
Labels
version=frr-7_4-dev-2099-gf41f38d88git=https_//github_com/frrouting/frr_gitbuildurl=https_//ci1_netdef_org/browse/frr-frr-3539branch=master
Revision
f41f38d88df2e09cb9d257c39dd6c0f322461b75 f41f38d88df2e09cb9d257c39dd6c0f322461b75
Total tests
9388
Successful since
#3537 ()

Tests

Code commits

Author Commit Message Commit date
David Lamparter David Lamparter f41f38d88df2e09cb9d257c39dd6c0f322461b75 f41f38d88df2e09cb9d257c39dd6c0f322461b75 Merge pull request #6787 from toreanderson/master
tools: do not silently ignore errors when loading config during startup
Tore Anderson <tore@fud.no> Tore Anderson <tore@fud.no> e220f954de174109f980467ec6a3d02eb0e93814 m e220f954de174109f980467ec6a3d02eb0e93814 tools: do not silently ignore errors when loading config during startup
Drop the `-n` (`--noerror`) flag from the `vtysh -b` invocation called by the
init script responsible for starting FRR. This ensures that errors in the
configuration file is propagated to the administrator, and prevents a node from
entering a production network while running an essentially undefined
configuration (a behaviour that I can personally attest to has the potential to
cause disastrous network outages - documented in more detail in Cumulus
Networks CS#12791).

Silently ignoring errors also leads to the rather odd behaviour that starting
FRR will ostensibly succeed, while reloading it immediately after - without
changing the configuration - will fail. This is due to the fact that the `-n`
flag is not used while reloading.

The use of the `-n` flag appears to have been introduced without any
explanation in commit 858aa29c6862ed2390baee53b6fc9f54e65246e2 by @donaldsharp.
Looking at the commit message, I suspect that it was not an intentional change.
It seems more likely to me that it was just meant to be used during testing and
development, but ended up being committed to master by accident.

Ticket:CM-28003

Signed-off-by: Tore Anderson <tore@fud.no>

Jira issues

IssueDescriptionStatus
Unknown Issue TypeCM-28003Could not obtain issue details from Jira
Unknown Issue TypeFRR-7Could not obtain issue details from Jira