-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[frrcfgd] Support for FRR configuration based on config DB events #5142
Conversation
HLD: sonic-net/SONiC#544 |
This pull request introduces 13 alerts when merging 288986c into c3202d8 - view on LGTM.com new alerts:
|
@zhaozhenhong |
This pull request introduces 13 alerts when merging 2a5c58e into f3feb56 - view on LGTM.com new alerts:
|
Fix has been added with latest commit |
This pull request introduces 3 alerts when merging e942575 into f3feb56 - view on LGTM.com new alerts:
|
@lguohan @ben-gale Please let us know the next step on this PR. |
I think this is the right approach if MSFT wants to partition out some of the changes from their world. Somewhere else I saw a proposal to define cloud vs. enterprise builds, and use this as a selector, but I think this is too broad, and will create arguments (i.e. what should be in cloud vs. enterprise?). |
@lguohan @tahmed-dev Can you please review the recent commit and merge the PR if everything looks good? also, label "Request for 202012 branch" this PR for 202012 release. |
retest Azure.sonic-buildimage please |
…ork_config is true (#5142) - Support for non-template based FRR configurations (BGP, route-map, OSPF, static route..etc) using config DB schema. - Support for save & restore - Jinja template based config-DB data read and apply to FRR during startup **- How I did it** - add frrcfgd service - when frr_mgmg_framework_config is set, frrcfgd starts in bgp container - when user changed the BGP or other related table entries in config DB, frrcfgd will run corresponding VTYSH commands to program on FRR. - add jinja template to generate FRR config file to be used by FRR daemons while bgp container restarted **- How to verify it** 1. Add/delete data on config DB and then run VTYSH "show running-config" command to check if FRR configuration changed. 1. Restart bgp container and check if generated FRR config file is correct and run VTYSH "show running-config" command to check if FRR configuration is consistent with attributes in config DB Co-authored-by: Zhenhong Zhao <zhenhong.zhao@dell.com>
@lguohan @pavel-shirshov @tahmed-dev - to get these changes in 202012 branch need help with the label. Dell doesn't have permissions to add label. |
Done! |
@zhaozhenhong seems frrcfgd.py have problem in dependency processing between different config db tables. For example: step1 initial data with (BGP_GLOBALS, BGP_NEIGHBOR). step2 delete asn from BGP_GLOBLAS. result to BGP_NEIGHBOR data aslo removed from bgpd.conf. step3, restore asn again. router bgp {} vrf {} is success, while BGP_NEIGHBOR not. |
- Why I did it
- How I did it
Added a new script and corresponding service. Based on the settings in DEVICE_METADATA table, new service will be started along with the bgp container start. And when user changed the BGP or other related table entries in config DB, the daemon will run corresponding VTYSH commands to program on FRR.
Also added jinja template to generate FRR config file to be used by FRR daemons while bgp container restarted
- How to verify it
- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)