diff options
Diffstat (limited to 'doc/developer')
| -rw-r--r-- | doc/developer/next-hop-tracking.rst | 2 | ||||
| -rw-r--r-- | doc/developer/testing.rst | 1 | ||||
| -rw-r--r-- | doc/developer/topotests-jsontopo.rst | 88 | ||||
| -rw-r--r-- | doc/developer/workflow.rst | 28 |
4 files changed, 72 insertions, 47 deletions
diff --git a/doc/developer/next-hop-tracking.rst b/doc/developer/next-hop-tracking.rst index a9af5e749c..99e1d65c2b 100644 --- a/doc/developer/next-hop-tracking.rst +++ b/doc/developer/next-hop-tracking.rst @@ -111,8 +111,6 @@ provides the following APIs: +============================+==================================================+ | bgp_find_or_add_nexthop() | find or add a nexthop in BGP nexthop table | +----------------------------+--------------------------------------------------+ -| bgp_find_nexthop() | find a nexthop in BGP nexthop table | -+----------------------------+--------------------------------------------------+ | bgp_parse_nexthop_update() | parse a nexthop update message coming from zebra | +----------------------------+--------------------------------------------------+ diff --git a/doc/developer/testing.rst b/doc/developer/testing.rst index 6396faf9a6..5865a6becc 100644 --- a/doc/developer/testing.rst +++ b/doc/developer/testing.rst @@ -8,3 +8,4 @@ Testing :maxdepth: 2 topotests + topotests-jsontopo diff --git a/doc/developer/topotests-jsontopo.rst b/doc/developer/topotests-jsontopo.rst index 130f072b62..bbae80f11d 100644 --- a/doc/developer/topotests-jsontopo.rst +++ b/doc/developer/topotests-jsontopo.rst @@ -1,53 +1,50 @@ -.. role:: raw-html-m2r(raw) - :format: html +.. _topotests-json: -************************************* -FRRouting Topology Tests with Mininet -************************************* +Topotests with JSON +=================== Overview -======== +-------- On top of current topotests framework following enhancements are done: -#. Creating the topology and assigning IPs to router' interfaces dynamically.\ :raw-html-m2r:`<br>` - It is achieved by using json file, in which user specify the number of routers, - links to each router, interfaces for the routers and protocol configurations for - all routers. +* Creating the topology and assigning IPs to router' interfaces dynamically. + It is achieved by using json file, in which user specify the number of + routers, links to each router, interfaces for the routers and protocol + configurations for all routers. -#. Creating the configurations dynamically. It is achieved by using - /usr/lib/frr/frr-reload.py utility, which takes running configuration and the - newly created configuration for any particular router and creates a delta - file(diff file) and loads it to router. +* Creating the configurations dynamically. It is achieved by using + :file:`/usr/lib/frr/frr-reload.py` utility, which takes running configuration + and the newly created configuration for any particular router and creates a + delta file(diff file) and loads it to router. Logging of test case executions -=============================== +------------------------------- - -#. User can enable logging of testcases execution messages into log file by - adding "frrtest_log_dir = /tmp/topotests/" in pytest.ini file -#.Router's current configuration can be displyed on console or sent to logs by - adding "show_router_config = True" in pytest.ini file +* The user can enable logging of testcases execution messages into log file by + adding ``frrtest_log_dir = /tmp/topotests/`` in :file:`pytest.ini`. +* Router's current configuration can be displyed on console or sent to logs by + adding ``show_router_config = True`` in :file:`pytest.ini`. Log file name will be displayed when we start execution: .. code-block:: console - root@test:~/topotests/example-topojson-test/test_topo_json_single_link# python - test_topo_json_single_link.py Logs will be sent to logfile: + root@test:# python ./test_topo_json_single_link.py + + Logs will be sent to logfile: /tmp/topotests/test_topo_json_single_link_11:57:01.353797 Note: directory "/tmp/topotests/" is created by topotests by default, making use of same directory to save execution logs. - Guidelines -========== +---------- Writing New Tests ------------------ +^^^^^^^^^^^^^^^^^ This section will guide you in all recommended steps to produce a standard topology test. @@ -60,29 +57,30 @@ This is the recommended test writing routine: * Write the tests * Create a Pull Request + File Hierarchy --------------- +^^^^^^^^^^^^^^ Before starting to write any tests one must know the file hierarchy. The repository hierarchy looks like this: -.. code-block:: - - $ cd path/to/topotests - $ find ./* - ... - ./example-topojson-test # the basic example test topology-1 - ./example-topojson-test/test_example_topojson.json # input json file, having - topology, interfaces, bgp and other configuration - ./example-topojson-test/test_example_topojson.py # test script to write and - execute testcases - ... - ./lib # shared test/topology functions - ./lib/topojson.py # library to create topology and configurations dynamically - from json file - ./lib/common_config.py # library to create protocol's common configurations ex- - static_routes, prefix_lists, route_maps etc. - ./lib/bgp.py # library to create only bgp configurations +.. code-block:: console + + $ cd path/to/topotests + $ find ./* + ... + ./example-topojson-test # the basic example test topology-1 + ./example-topojson-test/test_example_topojson.json # input json file, having + topology, interfaces, bgp and other configuration + ./example-topojson-test/test_example_topojson.py # test script to write and + execute testcases + ... + ./lib # shared test/topology functions + ./lib/topojson.py # library to create topology and configurations dynamically + from json file + ./lib/common_config.py # library to create protocol's common configurations ex- + static_routes, prefix_lists, route_maps etc. + ./lib/bgp.py # library to create only bgp configurations Defining the Topology and initial configuration in JSON file ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -325,7 +323,7 @@ BGP neighborship with Multiple phy-links, sample JSON file:: ... -JSON File Explained +JSON File Explained """"""""""""""""""" Mandatory keywords/options in JSON: @@ -466,7 +464,7 @@ Example: * ``__main__`` initialization code (to support running the script directly) .. code-block:: python - + if **name** == '\ **main**\ ': sys.exit(pytest.main(["-s"])) diff --git a/doc/developer/workflow.rst b/doc/developer/workflow.rst index c2e3724df2..6eef7532b3 100644 --- a/doc/developer/workflow.rst +++ b/doc/developer/workflow.rst @@ -163,6 +163,34 @@ releases have support for this feature request. Moreover, introducing features requests may result in breaking the stability of the branch. LTS branches are first done to bring long term support for stability. +Development Branches +-------------------- + +Occassionally the community will desire the ability to work together +on a feature that is considered useful to FRR. In this case the +parties may ask the Maintainers for the creation of a development +branch in the main FRR repository. Requirements for this to happen +are: + +- A one paragraph description of the feature being implemented to + allow for the facilitation of discussion about the feature. This + might include pointers to relevant RFC's or presentations that + explain what is planned. This is intended to set a somewhat + low bar for organization. +- A branch maintainer must be named. This person is responsible for + keeping the branch up to date, and general communication about the + project with the other FRR Maintainers. Additionally this person + must already be a FRR Maintainer. +- Commits to this branch must follow the normal PR and commit process + as outlined in other areas of this document. The goal of this is + to prevent the current state where large features are submitted + and are so large they are difficult to review. + +After a development branch has completed the work together, a final +review can be made and the branch merged into master. If a development +branch is becomes un-maintained or not being actively worked on after +three months then the Maintainers can decide to remove the branch. + Changelog --------- The changelog will be the base for the release notes. A changelog entry for |