This utility script helps in generated formatted and consistent
change log including:
1- group logs per daemon
2- standarize daemon names (lowercase, end with d)
3- capitalize all log lines
4- no merge commits
caveat: comments are assumed to be in the form
daemon-name : message
Sample Output:
```
sharpd
Follow the practice on cli design for json output
Install route supports nexthop-seg6 (step3)
Install_routes_helper support zapi_route flags (step1)
snapcraft
Add missing dependency
Add pathd to frr snap daemons
Change base to ubuntu 18.04 and libyang 2.0.7
staticd
Convert typedef to enum
Fix distance processing
Fix late initialization of blackhole type
Output config using nb callbacks instead of operational data
```
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
Move the "longer-prefixes" option from show_ip_bgp_cmd to
show_ip_bgp_json_cmd so that is has access to JSON output.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Move the "route-map" option from show_ip_bgp_cmd to
show_ip_bgp_json_cmd so that is has access to JSON output.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Move the "filter-list" option from show_ip_bgp_cmd to
show_ip_bgp_json_cmd so that is has access to JSON output.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Move the "prefix-list" option from show_ip_bgp_cmd to
show_ip_bgp_json_cmd so that is has access to JSON output.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Move the "community-list" option from show_ip_bgp_cmd to
show_ip_bgp_json_cmd so that is has access to JSON output.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
For IPv4 matching, we have "match ip next-hop address A.B.C.D".
For IPv6 matching, we have "match ipv6 next-hop X:X::X:X".
To have consistency, let's add "address" keyword to IPv6 commands.
Old commands are preserved as hidden for backward compatibility.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
There was a historical blurb at the top of the process architecture
document that in several instances caused some confusion regarding
whether or not FRR supports multithreading. Remove this paragraph and
replace it with a summary of the page contents.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
It's strictly optional, but… the backtraces are really much better.
Specifically, `libunwind` is notably more capable in figuring out
function names compared to glibc/libexecinfo `backtrace_symbols()`.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* Separate process into stages; stage 1 is preparation, stage 2 is
staging, stage 3 is publishing
* Reorder some steps
* Remove some steps
* Elaborate on some steps
* Add some steps
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
Clarify process for editing changelog and updating the configure.ac
project version, as well as procedure for doing sanity testing prior to
creating the release tag.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
The `neighbor <peer> version <X>` command does not
exist. I am unable to find it going back to version
2.0 of FRR. So this command has been not in the system
for a very long time.
In any event bgp already supports version 4 of bgp and
it auto-negotiates this.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Sphinx tries to parse :c:function: as function prototype, which doesn't
quite work with macros.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Sphinx warns about a few nits here, just fix. (Note :option:`-E` can't
be used without a "option:: -E" definition, it's intended as a cross
reference.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
