diff options
Diffstat (limited to 'doc/developer')
| -rw-r--r-- | doc/developer/frr-release-procedure.rst | 181 | ||||
| -rw-r--r-- | doc/developer/maintainer-release-build.rst | 89 | ||||
| -rw-r--r-- | doc/developer/packaging.rst | 8 | ||||
| -rw-r--r-- | doc/developer/release-announcement-template.md | 40 | ||||
| -rw-r--r-- | doc/developer/subdir.am | 3 | ||||
| -rw-r--r-- | doc/developer/testing.rst | 1 | ||||
| -rw-r--r-- | doc/developer/topotests-jsontopo.rst | 671 | ||||
| -rw-r--r-- | doc/developer/workflow.rst | 31 |
8 files changed, 592 insertions, 432 deletions
diff --git a/doc/developer/frr-release-procedure.rst b/doc/developer/frr-release-procedure.rst new file mode 100644 index 0000000000..ff95aa04a9 --- /dev/null +++ b/doc/developer/frr-release-procedure.rst @@ -0,0 +1,181 @@ +.. _frr-release-procedure: + +FRR Release Procedure +===================== + +``<version>`` - version to be released, e.g. 7.3 +``origin`` - FRR upstream repository + +1. Checkout ``dev/<version>``. + + .. code-block:: console + + git checkout dev/<version> + +2. Create and push a new branch called ``stable/<version>`` based on the + ``dev/<version>`` branch. + + .. code-block:: console + + git checkout -b stable/<version> + git push origin stable/<version>:refs/heads/stable/<version> + +3. Update Changelog for Red Hat Packages: + + Edit :file:`redhat/frr.spec.in` and look for the ``%changelog`` section: + + - Change last (top of list) entry from ``%{version}`` to the **last** + released version number. For example, if ``<version>`` is ``7.3`` and the + last public release was ``7.2``, you would use ``7.2``, changing the file + like so:: + + * Tue Nov 7 2017 Martin Winter <mwinter@opensourcerouting.org> - %{version} + + to:: + + * Tue Nov 7 2017 Martin Winter <mwinter@opensourcerouting.org> - 7.2 + + - Add new entry to the top of the list with ``%{version}`` tag. Make sure + to watch the format, i.e. the day is always 2 characters, with the 1st + character being a space if the day is one digit. + + - Add the changelog text below this entry. + +4. Update Changelog for Debian Packages: + + Edit :file:`changelog-auto.in`: + + - Change last (top of list) entry from ``@VERSION@`` to the **last** + released version number. For example, if ``<version>`` is ``7.3`` and the + last public release was ``7.2``, you would use ``7.2``, changing the file + like so:: + + frr (@VERSION@) RELEASED; urgency=medium + + to:: + + frr (7.2) RELEASED; urgency=medium + + - Add a new entry to the top of the list with a ``@VERSION@`` tag. Make sure + to watch the format. + + - Add the changelog text below this entry. + + - Verify the changelog format using ``dpkg-parsechangelog``. In the + repository root: + + .. code-block:: console + + dpkg-parsechangelog + + You should see output like this:: + + vagrant@local ~/frr> dpkg-parsechangelog + Source: frr + Version: 7.3-dev-0 + Distribution: UNRELEASED + Urgency: medium + Maintainer: FRRouting-Dev <dev@lists.frrouting.org> + Timestamp: 1540478210 + Date: Thu, 25 Oct 2018 16:36:50 +0200 + Changes: + frr (7.3-dev-0) RELEASED; urgency=medium + . + * Your Changes Here + +5. Change main version number: + + - Edit :file:`configure.ac` and change version in the ``AC_INIT`` command + to ``<version>`` + +6. Commit the changes, adding the changelog to the commit message. Follow all + existing commit guidelines. + +7. Create and submit a GitHub pull request, with the ``HEAD`` set to + ``stable/<version>`` and the base set to the upstream ``master`` branch. + Allow NetDef CI to complete its run and verify that all package builds were + successful. + +8. Create a git tag for the version: + + .. code-block:: console + + git tag -a frr-<version> -m "FRRouting Release <version>" + +9. Push the commit and new tag. + + .. code-block:: console + + git push origin stable/<version>:refs/head/stable/<version> + git push origin frr-<version> + +10. Kick off the Release build plan on the CI system for the correct release. + Contact Martin Winter for this step. Ensure all release packages build + successfully. + +11. Kick off the Snapcraft build plan for the release. + +12. Acquire the release RPM binary packages from Martin Winter. + +13. On GitHub, go to the <https://github.com/FRRouting/frr/releases>_ and click + "Draft a new release". Write a release announcement. The release + announcement should follow the template in + ``release-announcement-template.md``, located next to this document. Check + for spelling errors, and optionally (but preferably) have other maintainers + proofread the announcement text. + + Attach **only** the binary RPM packages to the GitHub release using + GitHub's attachment functionality. Do not attach Debian packages. Do not + attach source tarballs - these will be generated and attached by GitHub + automatically. Do not publish the release yet. + +14. Contact the current Debian maintainer for FRR to get new Debian packages + built and published on our APT repository at https://deb.frrouting.net/. + Ensure the webpage text is updated. Verify that new packages install + successfully on a vanilla Debian installation using the instructions on the + webpage. + +15. Deploy Snapcraft release (after CI system finishes the tests for snapcraft + testplan). + +16. Update the Read The Docs instance to being publishing documentation built + off the ``stable/<version>`` branch. Contact Quentin Young for this step. + +17. Publish the GitHub release. + +18. Clone the ``frr-www`` repository: + + .. code-block:: console + + git clone https://github.com/FRRouting/frr-www.git + +19. Add a new release announcement, using a previous announcement as template: + + .. code-block:: console + + cp <old-version>-launch.md <version>-launch.md + + Paste the GitHub release announcement text into this document, and **remove + line breaks**. In other words, this:: + + This is one continuous + sentence that should be + rendered on one line + + Needs to be changed to this:: + + This is one continuous sentence that should be rendered on one line + + This is very important otherwise the announcement will be unreadable on the + website. + + Make sure to add a link to the GitHub releases page at the top. + + Once finished, manually add a new entry into ``index.html`` to link to this + new announcement. Look at past commits to see how to do this. + +20. Deploy the updated ``frr-www`` on the frrouting.org web server and verify + that the announcement text is visible. + +21. Send an email to ``announce@lists.frrouting.org``. The text of this email + should include the text from the GitHub release. diff --git a/doc/developer/maintainer-release-build.rst b/doc/developer/maintainer-release-build.rst deleted file mode 100644 index 7792173034..0000000000 --- a/doc/developer/maintainer-release-build.rst +++ /dev/null @@ -1,89 +0,0 @@ -Release Build Procedure for FRR Maintainers -=========================================== - -1. Rename branch (if needed) - -.. code-block:: shell - - git clone git@github.com:FRRouting/frr.git - cd frr - git checkout dev/5.0 - git push origin :refs/heads/dev/5.0 - git push origin dev/5.0:refs/heads/stable/5.0 - -2. Checkout the new stable branch: - -.. code-block:: shell - - git checkout stable/5.0 - -3. Update Changelog for RedHat Package: - - Edit :file:`redhat/frr.spec.in` and look for the ``%changelog`` section: - - - Change last (top of list) entry from ``%{version}`` to previous fixed - version number, i.e.:: - - * Tue Nov 7 2017 Martin Winter <mwinter@opensourcerouting.org> - %{version} - - to:: - - * Tue Nov 7 2017 Martin Winter <mwinter@opensourcerouting.org> - 3.0.2 - - - Add new entry to the top of the list with ``%{version}`` tag and changelog - for version. - Make sure to watch the format, i.e. the day is always 2 characters, with - the 1st character being a space if the day is one digit. - -4. Update Changelog for Debian Packages: - - Edit :file:`debian/changelog-auto.in`: - - - Change last (top of list) entry from ``@VERSION@`` to previous fixed - version number, i.e.:: - - frr (@VERSION@) RELEASED; urgency=medium - - to:: - - frr (3.0.2) RELEASED; urgency=medium - - - Add a new entry to the top of the list with a ``@VERSION@`` tag and - changelog for version. - -5. Change main version number: - - - Edit :file:`configure.ac` and change version in the ``AC_INIT`` command - - Create a new entry with the version as ``%{version}`` tag - -6. Test building at least a Red Hat and Ubuntu package (or create a PR to have - the CI system test them) - -7. Commit the changes, adding the changelog to the commit message - -8. Create a git tag for the version: - - .. code-block:: shell - - git tag -a frr-5.0 -m "FRRouting Release 5.0" - -9. Push the commit and tag(s) and watch for errors on CI: - - .. code-block:: shell - - git push - git push --tags - -10. Kick off the Release build plan on the CI system for the correct release - -11. Send a Release Announcement with changes to - ``announce@lists.frrouting.org`` - -12. Kick off the Snapcraft build plan for the correct release - -13. After CI plans succeed, release on GitHub by going to - https://github.com/FRRouting/frr/releases and selecting "Draft a new - release". - -14. Deploy Snapcraft release (after CI system finishes the tests for snapcraft - testplan) diff --git a/doc/developer/packaging.rst b/doc/developer/packaging.rst index b174a9660c..0c072e4d16 100644 --- a/doc/developer/packaging.rst +++ b/doc/developer/packaging.rst @@ -1,10 +1,10 @@ -********* -Packaging -********* +******************** +Releases & Packaging +******************** .. toctree:: :maxdepth: 2 - maintainer-release-build + frr-release-procedure packaging-debian packaging-redhat diff --git a/doc/developer/release-announcement-template.md b/doc/developer/release-announcement-template.md new file mode 100644 index 0000000000..658b87eada --- /dev/null +++ b/doc/developer/release-announcement-template.md @@ -0,0 +1,40 @@ +<!--- +name: release-announcement-template +about: Template to use when drafing a new release announcement. DELETE THIS + BLOCK BEFORE PUBLISHING. +---> + +We are pleased to announce FRR <version>. + +<!-- Add a brief summary of major changes here --> + +Thank you to all contributors! + +Changelog +--------- + +<!-- List **only** user-visible changes in this section. When listing changes to individual daemons, alphabetize the list by daemon name. --> + +**All daemons:** +- <!-- List changes to all daemons --> + +<!-- If a new daemon was added, list it at the top here --> +**New daemon: <new>** +- Adds support for <protocol/feature> + +**daemon 1** +- <!-- List changes --> + +**daemon 2** +- <!-- List changes --> + +**daemon N** +- <!-- List changes --> + +### Internal improvements + +- <!-- List **only** user-invisible changes here --> + +### Packaging changes + +- <!-- List any new or removed packages here --> diff --git a/doc/developer/subdir.am b/doc/developer/subdir.am index 557a41c51f..2c49d6b875 100644 --- a/doc/developer/subdir.am +++ b/doc/developer/subdir.am @@ -26,6 +26,7 @@ dev_RSTFILES = \ doc/developer/building.rst \ doc/developer/cli.rst \ doc/developer/conf.py \ + doc/developer/frr-release-procedure.rst \ doc/developer/hooks.rst \ doc/developer/include-compile.rst \ doc/developer/index.rst \ @@ -33,7 +34,6 @@ dev_RSTFILES = \ doc/developer/lists.rst \ doc/developer/locking.rst \ doc/developer/logging.rst \ - doc/developer/maintainer-release-build.rst \ doc/developer/memtypes.rst \ doc/developer/modules.rst \ doc/developer/next-hop-tracking.rst \ @@ -55,6 +55,7 @@ EXTRA_DIST += \ $(dev_RSTFILES) \ doc/developer/draft-zebra-00.ms \ doc/developer/ldpd-basic-test-setup.md \ + doc/developer/release-announcement-template.md \ # end DEVBUILD = doc/developer/_build 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 65bdcbe9cf..bbae80f11d 100644 --- a/doc/developer/topotests-jsontopo.rst +++ b/doc/developer/topotests-jsontopo.rst @@ -1,376 +1,371 @@ -.. 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: -root@test:~/topotests/example-topojson-test/test_topo_json_single_link# python -test_topo_json_single_link.py Logs will be sent to logfile: -/tmp/topotests/test_topo_json_single_link_11:57:01.353797 + +.. code-block:: console + + 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. +This section will guide you in all recommended steps to produce a standard +topology test. This is the recommended test writing routine: - * Create a json file , which will have routers and protocol configurations * Create topology from json * Create configuration from json * 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 -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The first step to write a new test is to define the topology and initial configuration. User has to define topology and initial configuration in JSON -file. Here is an example of JSON file. - -.. code-block:: - - BGP neihghborship with single phy-link, sample JSON file: - { - "ipv4base": "192.168.0.0", - "ipv4mask": 30, - "ipv6base": "fd00::", - "ipv6mask": 64, - "link_ip_start": {"ipv4": "192.168.0.0", "v4mask": 30, "ipv6": "fd00::", "v6mask": 64}, - "lo_prefix": {"ipv4": "1.0.", "v4mask": 32, "ipv6": "2001:DB8:F::", "v6mask": 128}, - "routers": { - "r1": { - "links": { - "lo": {"ipv4": "auto", "ipv6": "auto", "type": "loopback"}, - "r2": {"ipv4": "auto", "ipv6": "auto"}, - "r3": {"ipv4": "auto", "ipv6": "auto"} - }, - "bgp": { - "local_as": "64512", - "address_family": { - "ipv4": { - "unicast": { - "neighbor": { - "r2": { - "dest_link": { - "r1": {} - } - }, - "r3": { - "dest_link": { - "r1": {} - } - } - } - } - } - } - } - }, - "r2": { - "links": { - "lo": {"ipv4": "auto", "ipv6": "auto", "type": "loopback"}, - "r1": {"ipv4": "auto", "ipv6": "auto"}, - "r3": {"ipv4": "auto", "ipv6": "auto"} - }, - "bgp": { - "local_as": "64512", - "address_family": { - "ipv4": { - "unicast": { - "redistribute": [ - { - "redist_type": "static" - } - ], - "neighbor": { - "r1": { - "dest_link": { - "r2": {} - } - }, - "r3": { - "dest_link": { - "r2": {} - } - } - } - } - } - } - } - } - ... - - - BGP neighboship with loopback interface, sample JSON file: - { - "ipv4base": "192.168.0.0", - "ipv4mask": 30, - "ipv6base": "fd00::", - "ipv6mask": 64, - "link_ip_start": {"ipv4": "192.168.0.0", "v4mask": 30, "ipv6": "fd00::", "v6mask": 64}, - "lo_prefix": {"ipv4": "1.0.", "v4mask": 32, "ipv6": "2001:DB8:F::", "v6mask": 128}, - "routers": { - "r1": { - "links": { - "lo": {"ipv4": "auto", "ipv6": "auto", "type": "loopback", - "add_static_route":"yes"}, - "r2": {"ipv4": "auto", "ipv6": "auto"} - }, - "bgp": { - "local_as": "64512", - "address_family": { - "ipv4": { - "unicast": { - "neighbor": { - "r2": { - "dest_link": { - "lo": { - "source_link": "lo" - } - } - } - } - } - } - } - }, - "static_routes": [ - { - "network": "1.0.2.17/32", - "next_hop": "192.168.0.1 - } - ] - }, - "r2": { - "links": { - "lo": {"ipv4": "auto", "ipv6": "auto", "type": "loopback", - "add_static_route":"yes"}, - "r1": {"ipv4": "auto", "ipv6": "auto"}, - "r3": {"ipv4": "auto", "ipv6": "auto"} - }, - "bgp": { - "local_as": "64512", - "address_family": { - "ipv4": { - "unicast": { - "redistribute": [ - { - "redist_type": "static" - } - ], - "neighbor": { - "r1": { - "dest_link": { - "lo": { - "source_link": "lo" - } - } - }, - "r3": { - "dest_link": { - "lo": { - "source_link": "lo" - } - } - } - } - } - } - } - }, - "static_routes": [ - { - "network": "192.0.20.1/32", - "no_of_ip": 9, - "admin_distance": 100, - "next_hop": "192.168.0.1", - "tag": 4001 - } - ], - } - ... - - BGP neighborship with Multiple phy-links, sample JSON file: - { - "ipv4base": "192.168.0.0", - "ipv4mask": 30, - "ipv6base": "fd00::", - "ipv6mask": 64, - "link_ip_start": {"ipv4": "192.168.0.0", "v4mask": 30, "ipv6": "fd00::", "v6mask": 64}, - "lo_prefix": {"ipv4": "1.0.", "v4mask": 32, "ipv6": "2001:DB8:F::", "v6mask": 128}, - "routers": { - "r1": { - "links": { - "lo": {"ipv4": "auto", "ipv6": "auto", "type": "loopback"}, - "r2-link1": {"ipv4": "auto", "ipv6": "auto"}, - "r2-link2": {"ipv4": "auto", "ipv6": "auto"} - }, - "bgp": { - "local_as": "64512", - "address_family": { - "ipv4": { - "unicast": { - "neighbor": { - "r2": { - "dest_link": { - "r1-link1": {} - } - } - } - } - } - } - } - }, - "r2": { - "links": { - "lo": {"ipv4": "auto", "ipv6": "auto", "type": "loopback"}, - "r1-link1": {"ipv4": "auto", "ipv6": "auto"}, - "r1-link2": {"ipv4": "auto", "ipv6": "auto"}, - "r3-link1": {"ipv4": "auto", "ipv6": "auto"}, - "r3-link2": {"ipv4": "auto", "ipv6": "auto"} - }, - "bgp": { - "local_as": "64512", - "address_family": { - "ipv4": { - "unicast": { - "redistribute": [ - { - "redist_type": "static" - } - ], - "neighbor": { - "r1": { - "dest_link": { - "r2-link1": {} - } - }, - "r3": { - "dest_link": { - "r2-link1": {} - } - } - } - } - } - } - } - } - ... - - -JSON file explained +file. Here is an example of JSON file:: + + BGP neihghborship with single phy-link, sample JSON file: + { + "ipv4base": "192.168.0.0", + "ipv4mask": 30, + "ipv6base": "fd00::", + "ipv6mask": 64, + "link_ip_start": {"ipv4": "192.168.0.0", "v4mask": 30, "ipv6": "fd00::", "v6mask": 64}, + "lo_prefix": {"ipv4": "1.0.", "v4mask": 32, "ipv6": "2001:DB8:F::", "v6mask": 128}, + "routers": { + "r1": { + "links": { + "lo": {"ipv4": "auto", "ipv6": "auto", "type": "loopback"}, + "r2": {"ipv4": "auto", "ipv6": "auto"}, + "r3": {"ipv4": "auto", "ipv6": "auto"} + }, + "bgp": { + "local_as": "64512", + "address_family": { + "ipv4": { + "unicast": { + "neighbor": { + "r2": { + "dest_link": { + "r1": {} + } + }, + "r3": { + "dest_link": { + "r1": {} + } + } + } + } + } + } + } + }, + "r2": { + "links": { + "lo": {"ipv4": "auto", "ipv6": "auto", "type": "loopback"}, + "r1": {"ipv4": "auto", "ipv6": "auto"}, + "r3": {"ipv4": "auto", "ipv6": "auto"} + }, + "bgp": { + "local_as": "64512", + "address_family": { + "ipv4": { + "unicast": { + "redistribute": [ + { + "redist_type": "static" + } + ], + "neighbor": { + "r1": { + "dest_link": { + "r2": {} + } + }, + "r3": { + "dest_link": { + "r2": {} + } + } + } + } + } + } + } + } + ... + + +BGP neighboship with loopback interface, sample JSON file:: + + { + "ipv4base": "192.168.0.0", + "ipv4mask": 30, + "ipv6base": "fd00::", + "ipv6mask": 64, + "link_ip_start": {"ipv4": "192.168.0.0", "v4mask": 30, "ipv6": "fd00::", "v6mask": 64}, + "lo_prefix": {"ipv4": "1.0.", "v4mask": 32, "ipv6": "2001:DB8:F::", "v6mask": 128}, + "routers": { + "r1": { + "links": { + "lo": {"ipv4": "auto", "ipv6": "auto", "type": "loopback", + "add_static_route":"yes"}, + "r2": {"ipv4": "auto", "ipv6": "auto"} + }, + "bgp": { + "local_as": "64512", + "address_family": { + "ipv4": { + "unicast": { + "neighbor": { + "r2": { + "dest_link": { + "lo": { + "source_link": "lo" + } + } + } + } + } + } + } + }, + "static_routes": [ + { + "network": "1.0.2.17/32", + "next_hop": "192.168.0.1 + } + ] + }, + "r2": { + "links": { + "lo": {"ipv4": "auto", "ipv6": "auto", "type": "loopback", + "add_static_route":"yes"}, + "r1": {"ipv4": "auto", "ipv6": "auto"}, + "r3": {"ipv4": "auto", "ipv6": "auto"} + }, + "bgp": { + "local_as": "64512", + "address_family": { + "ipv4": { + "unicast": { + "redistribute": [ + { + "redist_type": "static" + } + ], + "neighbor": { + "r1": { + "dest_link": { + "lo": { + "source_link": "lo" + } + } + }, + "r3": { + "dest_link": { + "lo": { + "source_link": "lo" + } + } + } + } + } + } + } + }, + "static_routes": [ + { + "network": "192.0.20.1/32", + "no_of_ip": 9, + "admin_distance": 100, + "next_hop": "192.168.0.1", + "tag": 4001 + } + ], + } + ... + +BGP neighborship with Multiple phy-links, sample JSON file:: + + { + "ipv4base": "192.168.0.0", + "ipv4mask": 30, + "ipv6base": "fd00::", + "ipv6mask": 64, + "link_ip_start": {"ipv4": "192.168.0.0", "v4mask": 30, "ipv6": "fd00::", "v6mask": 64}, + "lo_prefix": {"ipv4": "1.0.", "v4mask": 32, "ipv6": "2001:DB8:F::", "v6mask": 128}, + "routers": { + "r1": { + "links": { + "lo": {"ipv4": "auto", "ipv6": "auto", "type": "loopback"}, + "r2-link1": {"ipv4": "auto", "ipv6": "auto"}, + "r2-link2": {"ipv4": "auto", "ipv6": "auto"} + }, + "bgp": { + "local_as": "64512", + "address_family": { + "ipv4": { + "unicast": { + "neighbor": { + "r2": { + "dest_link": { + "r1-link1": {} + } + } + } + } + } + } + } + }, + "r2": { + "links": { + "lo": {"ipv4": "auto", "ipv6": "auto", "type": "loopback"}, + "r1-link1": {"ipv4": "auto", "ipv6": "auto"}, + "r1-link2": {"ipv4": "auto", "ipv6": "auto"}, + "r3-link1": {"ipv4": "auto", "ipv6": "auto"}, + "r3-link2": {"ipv4": "auto", "ipv6": "auto"} + }, + "bgp": { + "local_as": "64512", + "address_family": { + "ipv4": { + "unicast": { + "redistribute": [ + { + "redist_type": "static" + } + ], + "neighbor": { + "r1": { + "dest_link": { + "r2-link1": {} + } + }, + "r3": { + "dest_link": { + "r2-link1": {} + } + } + } + } + } + } + } + } + ... + + +JSON File Explained """"""""""""""""""" Mandatory keywords/options in JSON: - -* "ipv4base" : base ipv4 address to generate ips, ex - 192.168.0.0 -* "ipv4mask" : mask for ipv4 address, ex - 30 -* "ipv6base" : base ipv6 address to generate ips, ex - fd00: -* "ipv6mask" : mask for ipv6 address, ex - 64 -* "link_ip_start" : physical interface base ipv4 and ipv6 address -* "lo_prefix" : loopback interface base ipv4 and ipv6 address -* "routers" : user can add number of routers as per topology, router's name +* ``ipv4base`` : base ipv4 address to generate ips, ex - 192.168.0.0 +* ``ipv4mask`` : mask for ipv4 address, ex - 30 +* ``ipv6base`` : base ipv6 address to generate ips, ex - fd00: +* ``ipv6mask`` : mask for ipv6 address, ex - 64 +* ``link_ip_start`` : physical interface base ipv4 and ipv6 address +* ``lo_prefix`` : loopback interface base ipv4 and ipv6 address +* ``routers`` : user can add number of routers as per topology, router's name can be any logical name, ex- r1 or a0. -* "r1" : name of the router -* "lo" : loopback interface dict, ipv4 and/or ipv6 addresses generated automatically -* "type" : type of interface, to identify loopback interface -* "links" : physical interfaces dict, ipv4 and/or ipv6 addresses generated +* ``r1`` : name of the router +* ``lo`` : loopback interface dict, ipv4 and/or ipv6 addresses generated automatically +* ``type`` : type of interface, to identify loopback interface +* ``links`` : physical interfaces dict, ipv4 and/or ipv6 addresses generated automatically -* "r2-link1" : it will be used when routers have multiple links. 'r2' is router +* ``r2-link1`` : it will be used when routers have multiple links. 'r2' is router name, 'link' is any logical name, '1' is to identify link number, - router name and link must be seperated by hyphen ("-"), ex- a0-peer1 + router name and link must be seperated by hyphen (``-``), ex- a0-peer1 Optional keywords/options in JSON: -* "bgp" : bgp configuration -* "local_as" : Local AS number -* "unicast" : All SAFI configuration -* "neighbor": All neighbor details -* "dest_link" : Destination link to which router will connect -* "router_id" : bgp router-id -* "source_link" : if user wants to establish bgp neighborship with loopback - interface, add "source_link": "lo" -* "keepalivetimer" : Keep alive timer for BGP neighbor -* "holddowntimer" : Hold down timer for BGP neighbor -* "static_routes" : create static routes for routers -* "redistribute" : redistribute static and/or connected routes -* "prefix_lists" : create Prefix-lists for routers +* ``bgp`` : bgp configuration +* ``local_as`` : Local AS number +* ``unicast`` : All SAFI configuration +* ``neighbor``: All neighbor details +* ``dest_link`` : Destination link to which router will connect +* ``router_id`` : bgp router-id +* ``source_link`` : if user wants to establish bgp neighborship with loopback + interface, add ``source_link``: ``lo`` +* ``keepalivetimer`` : Keep alive timer for BGP neighbor +* ``holddowntimer`` : Hold down timer for BGP neighbor +* ``static_routes`` : create static routes for routers +* ``redistribute`` : redistribute static and/or connected routes +* ``prefix_lists`` : create Prefix-lists for routers Building topology and configurations """""""""""""""""""""""""""""""""""" Topology and initial configuration will be created in setup_module(). Following -is the sample code: - -.. code-block:: +is the sample code:: class TemplateTopo(Topo): def build(self, *_args, **_opts): @@ -438,38 +433,38 @@ to be used to reference the routers configuration file location Example: -* The topology class that inherits from Mininet Topo class +* The topology class that inherits from Mininet Topo class; -.. code-block:: + .. code-block:: python - class TemplateTopo(Topo): - def build(self, *_args, **_opts): - tgen = get_topogen(self) - # topology build code + class TemplateTopo(Topo): + def build(self, *_args, **_opts): + tgen = get_topogen(self) + # topology build code -* pytest setup_module() and teardown_module() to start the topology +* pytest setup_module() and teardown_module() to start the topology: -.. code-block:: + .. code-block:: python - def setup_module(_m): - tgen = Topogen(TemplateTopo) + def setup_module(_m): + tgen = Topogen(TemplateTopo) - # Starting topology, create tmp files which are loaded to routers - # to start deamons and then start routers - start_topology(tgen, CWD) + # Starting topology, create tmp files which are loaded to routers + # to start deamons and then start routers + start_topology(tgen, CWD) - def teardown_module(_m): - tgen = get_topogen() + def teardown_module(_m): + tgen = get_topogen() - # Stop toplogy and Remove tmp files - stop_topology(tgen, CWD) + # Stop toplogy and Remove tmp files + stop_topology(tgen, CWD) -* __main__ initialization code (to support running the script directly) +* ``__main__`` initialization code (to support running the script directly) -.. code-block:: + .. code-block:: python - if **name** == '\ **main**\ ': - sys.exit(pytest.main(["-s"])) + if **name** == '\ **main**\ ': + sys.exit(pytest.main(["-s"])) diff --git a/doc/developer/workflow.rst b/doc/developer/workflow.rst index 93d01bfbc1..6eef7532b3 100644 --- a/doc/developer/workflow.rst +++ b/doc/developer/workflow.rst @@ -113,6 +113,9 @@ Security fixes are backported to all releases less than or equal to at least one year old. Security fixes may also be backported to older releases depending on severity. +For detailed instructions on how to produce an FRR release, refer to +:ref:`frr-release-procedure`. + Long term support branches ( LTS ) ----------------------------------------- @@ -160,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 |