matthew/sonic-buildimage
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
5314ae0ec5
sonic-buildimage/rules/docker-fpm-frr.mk

45 lines
1.7 KiB
Makefile
Raw Normal View History

[build]: Adding support for Free-Range-Routing stack. (#510) - Extending SONiC building infrastructure to provide users with greater flexibility, by allowing them to elect a routing-stack different than the default one (quagga). The desired routing-stack will be defined in rules/config file. - As part of these changes I'm adding support for Free-Range-Routing (FRR) stack. Quagga will continue to be the default routing-stack. Signed-off-by: Rodny Molina <rodny@linkedin.com>
2017-04-20 11:12:27 -05:00
# docker image for fpm-frr
[build]: Added debug symbols to many debug dockers. (#3098) * Added debug symbols to many debug dockers. * For debug images *only*: 1) Archive source files into debug image 2) Archived source is copied into /src 3) Created an empty dir /debug 4) Mount both /src as ro & /debug as rw into every docker 5) Login banner will give some details on /src & /debug 6) Devs can copy core file into /debug and view it from inside a container. 7) Dev may create all gdb logs and other data directly into /debug. * Dropped redundant REDIS_TOOLS per review comments. * Added debug symbols to frr package and hence FRR based BGP docker. * 1) Moved dbg_files.sh to scripts/ 2) Src directories to archive are now collected from individual Makefiles. 3) Added few more debug symbols 4) Added few more debug dockers. Here after no more changes except per review comments. To debug: Install required version of debug image in Switch or VM. Copy core file into /debug of host Get into Docker gdb /usr/bin/<daemon> -c /debug/<your core file> set directory /src/... <-- inside gdb to get the source For non-in-depth debugging: Download corresponding debug Docker image (docker-...-dbg.gz) to your VM Load the image Run image with entrypoint as 'bash' with dir containing core mapped in. Run gdb on the core.
2019-07-04 00:13:55 -05:00
DOCKER_FPM_FRR_STEM = docker-fpm-frr
DOCKER_FPM_FRR = $(DOCKER_FPM_FRR_STEM).gz
DOCKER_FPM_FRR_DBG = $(DOCKER_FPM_FRR_STEM)-$(DBG_IMAGE_MARK).gz
$(DOCKER_FPM_FRR)_PATH = $(DOCKERS_PATH)/$(DOCKER_FPM_FRR_STEM)
[frrcfgd] introduce frrcfgd to manage frr config when frr_mgmt_framework_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>
2021-01-24 19:57:03 -06:00
$(DOCKER_FPM_FRR)_PYTHON_WHEELS += $(SONIC_BGPCFGD) $(SONIC_FRR_MGMT_FRAMEWORK)
[build]: Added debug symbols to many debug dockers. (#3098) * Added debug symbols to many debug dockers. * For debug images *only*: 1) Archive source files into debug image 2) Archived source is copied into /src 3) Created an empty dir /debug 4) Mount both /src as ro & /debug as rw into every docker 5) Login banner will give some details on /src & /debug 6) Devs can copy core file into /debug and view it from inside a container. 7) Dev may create all gdb logs and other data directly into /debug. * Dropped redundant REDIS_TOOLS per review comments. * Added debug symbols to frr package and hence FRR based BGP docker. * 1) Moved dbg_files.sh to scripts/ 2) Src directories to archive are now collected from individual Makefiles. 3) Added few more debug symbols 4) Added few more debug dockers. Here after no more changes except per review comments. To debug: Install required version of debug image in Switch or VM. Copy core file into /debug of host Get into Docker gdb /usr/bin/<daemon> -c /debug/<your core file> set directory /src/... <-- inside gdb to get the source For non-in-depth debugging: Download corresponding debug Docker image (docker-...-dbg.gz) to your VM Load the image Run image with entrypoint as 'bash' with dir containing core mapped in. Run gdb on the core.
2019-07-04 00:13:55 -05:00
Patch libyang1.0.184 so version and let frr 7.5 use the patched version
2020-11-23 18:45:34 -06:00
$(DOCKER_FPM_FRR)_DEPENDS += $(FRR) $(FRR_SNMP) $(SWSS) $(LIBYANG1)
[docker-fpm-frr]: Upgrade docker-fpm-frr to buster (#4920) Verify that /etc/apt/sources.list points to buster using docker exec bgp cat /etc/apt/sources.list BGP neighborship is established. root@sonic:~# show ip bgp summary IPv4 Unicast Summary: BGP router identifier 10.1.0.1, local AS number 65100 vrf-id 0 BGP table version 1 RIB entries 1, using 184 bytes of memory Peers 1, using 20 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 6.1.1.1 4 100 96 96 0 0 0 01:32:04 0 Total number of neighbors 1 root@sonic:~# Signed-off-by: Joyas Joseph <joyas_joseph@dell.com>
2020-07-29 16:19:03 -05:00
$(DOCKER_FPM_FRR)_DBG_DEPENDS = $($(DOCKER_CONFIG_ENGINE_BUSTER)_DBG_DEPENDS)
[build]: Added debug symbols to many debug dockers. (#3098) * Added debug symbols to many debug dockers. * For debug images *only*: 1) Archive source files into debug image 2) Archived source is copied into /src 3) Created an empty dir /debug 4) Mount both /src as ro & /debug as rw into every docker 5) Login banner will give some details on /src & /debug 6) Devs can copy core file into /debug and view it from inside a container. 7) Dev may create all gdb logs and other data directly into /debug. * Dropped redundant REDIS_TOOLS per review comments. * Added debug symbols to frr package and hence FRR based BGP docker. * 1) Moved dbg_files.sh to scripts/ 2) Src directories to archive are now collected from individual Makefiles. 3) Added few more debug symbols 4) Added few more debug dockers. Here after no more changes except per review comments. To debug: Install required version of debug image in Switch or VM. Copy core file into /debug of host Get into Docker gdb /usr/bin/<daemon> -c /debug/<your core file> set directory /src/... <-- inside gdb to get the source For non-in-depth debugging: Download corresponding debug Docker image (docker-...-dbg.gz) to your VM Load the image Run image with entrypoint as 'bash' with dir containing core mapped in. Run gdb on the core.
2019-07-04 00:13:55 -05:00
$(DOCKER_FPM_FRR)_DBG_DEPENDS += $(SWSS_DBG) $(LIBSWSSCOMMON_DBG) \
Patch libyang1.0.184 so version and let frr 7.5 use the patched version
2020-11-23 18:45:34 -06:00
$(FRR_DBG) $(FRR_SNMP_DBG) $(LIBYANG1_DBG)
[build]: Added debug symbols to many debug dockers. (#3098) * Added debug symbols to many debug dockers. * For debug images *only*: 1) Archive source files into debug image 2) Archived source is copied into /src 3) Created an empty dir /debug 4) Mount both /src as ro & /debug as rw into every docker 5) Login banner will give some details on /src & /debug 6) Devs can copy core file into /debug and view it from inside a container. 7) Dev may create all gdb logs and other data directly into /debug. * Dropped redundant REDIS_TOOLS per review comments. * Added debug symbols to frr package and hence FRR based BGP docker. * 1) Moved dbg_files.sh to scripts/ 2) Src directories to archive are now collected from individual Makefiles. 3) Added few more debug symbols 4) Added few more debug dockers. Here after no more changes except per review comments. To debug: Install required version of debug image in Switch or VM. Copy core file into /debug of host Get into Docker gdb /usr/bin/<daemon> -c /debug/<your core file> set directory /src/... <-- inside gdb to get the source For non-in-depth debugging: Download corresponding debug Docker image (docker-...-dbg.gz) to your VM Load the image Run image with entrypoint as 'bash' with dir containing core mapped in. Run gdb on the core.
2019-07-04 00:13:55 -05:00
[docker-fpm-frr]: Upgrade docker-fpm-frr to buster (#4920) Verify that /etc/apt/sources.list points to buster using docker exec bgp cat /etc/apt/sources.list BGP neighborship is established. root@sonic:~# show ip bgp summary IPv4 Unicast Summary: BGP router identifier 10.1.0.1, local AS number 65100 vrf-id 0 BGP table version 1 RIB entries 1, using 184 bytes of memory Peers 1, using 20 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 6.1.1.1 4 100 96 96 0 0 0 01:32:04 0 Total number of neighbors 1 root@sonic:~# Signed-off-by: Joyas Joseph <joyas_joseph@dell.com>
2020-07-29 16:19:03 -05:00
$(DOCKER_FPM_FRR)_DBG_IMAGE_PACKAGES = $($(DOCKER_CONFIG_ENGINE_BUSTER)_DBG_IMAGE_PACKAGES)
[build]: Added debug symbols to many debug dockers. (#3098) * Added debug symbols to many debug dockers. * For debug images *only*: 1) Archive source files into debug image 2) Archived source is copied into /src 3) Created an empty dir /debug 4) Mount both /src as ro & /debug as rw into every docker 5) Login banner will give some details on /src & /debug 6) Devs can copy core file into /debug and view it from inside a container. 7) Dev may create all gdb logs and other data directly into /debug. * Dropped redundant REDIS_TOOLS per review comments. * Added debug symbols to frr package and hence FRR based BGP docker. * 1) Moved dbg_files.sh to scripts/ 2) Src directories to archive are now collected from individual Makefiles. 3) Added few more debug symbols 4) Added few more debug dockers. Here after no more changes except per review comments. To debug: Install required version of debug image in Switch or VM. Copy core file into /debug of host Get into Docker gdb /usr/bin/<daemon> -c /debug/<your core file> set directory /src/... <-- inside gdb to get the source For non-in-depth debugging: Download corresponding debug Docker image (docker-...-dbg.gz) to your VM Load the image Run image with entrypoint as 'bash' with dir containing core mapped in. Run gdb on the core.
2019-07-04 00:13:55 -05:00
[docker-fpm-frr]: Upgrade docker-fpm-frr to buster (#4920) Verify that /etc/apt/sources.list points to buster using docker exec bgp cat /etc/apt/sources.list BGP neighborship is established. root@sonic:~# show ip bgp summary IPv4 Unicast Summary: BGP router identifier 10.1.0.1, local AS number 65100 vrf-id 0 BGP table version 1 RIB entries 1, using 184 bytes of memory Peers 1, using 20 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 6.1.1.1 4 100 96 96 0 0 0 01:32:04 0 Total number of neighbors 1 root@sonic:~# Signed-off-by: Joyas Joseph <joyas_joseph@dell.com>
2020-07-29 16:19:03 -05:00
$(DOCKER_FPM_FRR)_LOAD_DOCKERS += $(DOCKER_CONFIG_ENGINE_BUSTER)
[build]: Added debug symbols to many debug dockers. (#3098) * Added debug symbols to many debug dockers. * For debug images *only*: 1) Archive source files into debug image 2) Archived source is copied into /src 3) Created an empty dir /debug 4) Mount both /src as ro & /debug as rw into every docker 5) Login banner will give some details on /src & /debug 6) Devs can copy core file into /debug and view it from inside a container. 7) Dev may create all gdb logs and other data directly into /debug. * Dropped redundant REDIS_TOOLS per review comments. * Added debug symbols to frr package and hence FRR based BGP docker. * 1) Moved dbg_files.sh to scripts/ 2) Src directories to archive are now collected from individual Makefiles. 3) Added few more debug symbols 4) Added few more debug dockers. Here after no more changes except per review comments. To debug: Install required version of debug image in Switch or VM. Copy core file into /debug of host Get into Docker gdb /usr/bin/<daemon> -c /debug/<your core file> set directory /src/... <-- inside gdb to get the source For non-in-depth debugging: Download corresponding debug Docker image (docker-...-dbg.gz) to your VM Load the image Run image with entrypoint as 'bash' with dir containing core mapped in. Run gdb on the core.
2019-07-04 00:13:55 -05:00
[dockers] label SONiC Docker with manifest (#5939) Signed-off-by: Stepan Blyschak stepanb@nvidia.com This PR is part of SONiC Application Extension Depends on #5938 - Why I did it To provide an infrastructure change in order to support SONiC Application Extension feature. - How I did it Label every installable SONiC Docker with a minimal required manifest and auto-generate packages.json file based on installed SONiC images. - How to verify it Build an image, execute the following command: admin@sonic:~$ docker inspect docker-snmp:1.0.0 | jq '.[0].Config.Labels["com.azure.sonic.manifest"]' -r | jq Cat /var/lib/sonic-package-manager/packages.json file to verify all dockers are listed there.
2021-04-26 15:51:50 -05:00
$(DOCKER_FPM_FRR)_VERSION = 1.0.0
$(DOCKER_FPM_FRR)_PACKAGE_NAME = fpm-frr
[SONiC Application Extension] support warm/fast reboot for extension packages (#7286) #### Why I did it I made this change to support warm/fast reboot for SONiC extension packages as per HLD Azure/SONiC#682. #### How I did it I extended manifest.json.j2 with new warm/fast reboot related fields and also extended sonic_debian_extension.j2 script template to generate the shutdown order files for warm and fast reboot.
2021-07-11 08:58:05 -05:00
$(DOCKER_FPM_FRR)_WARM_SHUTDOWN_BEFORE = swss
$(DOCKER_FPM_FRR)_WARM_SHUTDOWN_AFTER = radv
$(DOCKER_FPM_FRR)_FAST_SHUTDOWN_BEFORE = swss
$(DOCKER_FPM_FRR)_FAST_SHUTDOWN_AFTER = radv
[dockers] label SONiC Docker with manifest (#5939) Signed-off-by: Stepan Blyschak stepanb@nvidia.com This PR is part of SONiC Application Extension Depends on #5938 - Why I did it To provide an infrastructure change in order to support SONiC Application Extension feature. - How I did it Label every installable SONiC Docker with a minimal required manifest and auto-generate packages.json file based on installed SONiC images. - How to verify it Build an image, execute the following command: admin@sonic:~$ docker inspect docker-snmp:1.0.0 | jq '.[0].Config.Labels["com.azure.sonic.manifest"]' -r | jq Cat /var/lib/sonic-package-manager/packages.json file to verify all dockers are listed there.
2021-04-26 15:51:50 -05:00
[build]: Adding support for Free-Range-Routing stack. (#510) - Extending SONiC building infrastructure to provide users with greater flexibility, by allowing them to elect a routing-stack different than the default one (quagga). The desired routing-stack will be defined in rules/config file. - As part of these changes I'm adding support for Free-Range-Routing (FRR) stack. Quagga will continue to be the default routing-stack. Signed-off-by: Rodny Molina <rodny@linkedin.com>
2017-04-20 11:12:27 -05:00
SONIC_DOCKER_IMAGES += $(DOCKER_FPM_FRR)
[build]: Added debug symbols to many debug dockers. (#3098) * Added debug symbols to many debug dockers. * For debug images *only*: 1) Archive source files into debug image 2) Archived source is copied into /src 3) Created an empty dir /debug 4) Mount both /src as ro & /debug as rw into every docker 5) Login banner will give some details on /src & /debug 6) Devs can copy core file into /debug and view it from inside a container. 7) Dev may create all gdb logs and other data directly into /debug. * Dropped redundant REDIS_TOOLS per review comments. * Added debug symbols to frr package and hence FRR based BGP docker. * 1) Moved dbg_files.sh to scripts/ 2) Src directories to archive are now collected from individual Makefiles. 3) Added few more debug symbols 4) Added few more debug dockers. Here after no more changes except per review comments. To debug: Install required version of debug image in Switch or VM. Copy core file into /debug of host Get into Docker gdb /usr/bin/<daemon> -c /debug/<your core file> set directory /src/... <-- inside gdb to get the source For non-in-depth debugging: Download corresponding debug Docker image (docker-...-dbg.gz) to your VM Load the image Run image with entrypoint as 'bash' with dir containing core mapped in. Run gdb on the core.
2019-07-04 00:13:55 -05:00
SONIC_DOCKER_DBG_IMAGES += $(DOCKER_FPM_FRR_DBG)
[build]: Adding support for Free-Range-Routing stack. (#510) - Extending SONiC building infrastructure to provide users with greater flexibility, by allowing them to elect a routing-stack different than the default one (quagga). The desired routing-stack will be defined in rules/config file. - As part of these changes I'm adding support for Free-Range-Routing (FRR) stack. Quagga will continue to be the default routing-stack. Signed-off-by: Rodny Molina <rodny@linkedin.com>
2017-04-20 11:12:27 -05:00
$(DOCKER_FPM_FRR)_CONTAINER_NAME = bgp
[baseimage]: support building multi-asic component (#3856) - move single instance services into their own folder - generate Systemd templates for any multi-instance service files in slave.mk - detect single or multi-instance platform in systemd-sonic-generator based on asic.conf platform specific file. - update container hostname after creation instead of during creation (docker_image_ctl) - run Docker containers in a network namespace if specified - add a service to create a simulated multi-ASIC topology on the virtual switch platform Signed-off-by: Lawrence Lee <t-lale@microsoft.com> Signed-off-by: Suvarna Meenakshi <Suvarna.Meenaksh@microsoft.com>
2020-01-26 15:56:42 -06:00
$(DOCKER_FPM_FRR)_RUN_OPT += --privileged -t
[build]: Adding support for Free-Range-Routing stack. (#510) - Extending SONiC building infrastructure to provide users with greater flexibility, by allowing them to elect a routing-stack different than the default one (quagga). The desired routing-stack will be defined in rules/config file. - As part of these changes I'm adding support for Free-Range-Routing (FRR) stack. Quagga will continue to be the default routing-stack. Signed-off-by: Rodny Molina <rodny@linkedin.com>
2017-04-20 11:12:27 -05:00
$(DOCKER_FPM_FRR)_RUN_OPT += -v /etc/sonic:/etc/sonic:ro
[Services] Restart BGP service upon unexpected critical process exit. (#4207)
2020-03-03 18:50:32 -06:00
$(DOCKER_FPM_FRR)_FILES += $(SUPERVISOR_PROC_EXIT_LISTENER_SCRIPT)
[build]: Adding support for Free-Range-Routing stack. (#510) - Extending SONiC building infrastructure to provide users with greater flexibility, by allowing them to elect a routing-stack different than the default one (quagga). The desired routing-stack will be defined in rules/config file. - As part of these changes I'm adding support for Free-Range-Routing (FRR) stack. Quagga will continue to be the default routing-stack. Signed-off-by: Rodny Molina <rodny@linkedin.com>
2017-04-20 11:12:27 -05:00
$(DOCKER_FPM_FRR)_BASE_IMAGE_FILES += vtysh:/usr/bin/vtysh
Support readonly vtysh for sudoers (#7383) Why I did it Support readonly version of the command vtysh How I did it Check if the command starting with "show", and verify only contains single command in script.
2021-04-25 03:32:02 -05:00
$(DOCKER_FPM_FRR)_BASE_IMAGE_FILES += rvtysh:/usr/bin/rvtysh
[bgp]: Implement Universal Traffic Shift for SONiC (#3209) * [bgp]: Implement Universal Traffic Shift for SONiC * Fix issue with ipv6 loopback match * Add tests
2019-07-26 16:31:56 -05:00
$(DOCKER_FPM_FRR)_BASE_IMAGE_FILES += TSA:/usr/bin/TSA
$(DOCKER_FPM_FRR)_BASE_IMAGE_FILES += TSB:/usr/bin/TSB
$(DOCKER_FPM_FRR)_BASE_IMAGE_FILES += TSC:/usr/bin/TSC
[docker-fpm-frr]: TSA/B/C changes for multi-asic (#6510) - Introduced TS common file in docker as well and moved common functions. - TSA/B/C scripts run only in BGP instances for front end ASICs. In addition skip enforcing it on route maps used between internal BGP sessions. admin@str--acs-1:~$ sudo /usr/bin/TSA System Mode: Normal -> Maintenance and in case of Multi-ASIC admin@str--acs-1:~$ sudo /usr/bin/TSA BGP0 : System Mode: Normal -> Maintenance BGP1 : System Mode: Normal -> Maintenance BGP2 : System Mode: Normal -> Maintenance
2021-02-12 12:56:44 -06:00
$(DOCKER_FPM_FRR)_BASE_IMAGE_FILES += TS:/usr/bin/TS
Add infra to support building Bullseye base image with Buster containers All docker containers will be built as Buster containers, from a Buster slave. The base image and remaining packages that are installed onto the host system will be built for Bullseye, from a Bullseye slave. Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
2021-06-30 14:45:40 -05:00
SONIC_BUSTER_DOCKERS += $(DOCKER_FPM_FRR)
SONIC_BUSTER_DBG_DOCKERS += $(DOCKER_FPM_FRR_DBG)
Reference in New Issue Copy Permalink