matthew/sonic-buildimage
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
946bc3b969
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
Frr 8.2 upgrade (#10691) Why I did it Upgrade FRR to version 8.2.2. Build libyang2 required by FRR. How I did it Update FRR version and tag. How to verify it Following tests were performed on sonic-vs: BGP docker status check BGP configuration and session establishment Route redistribution and ping Issued show commands to check the bgp neighbor and routes Checked app-db to ensure bgp routes are installed with correct interface and nexthop. Create VRF and check FRR knows the VRF Check VRF routes are installed in app-db with correct Vrf name and next-hop Establish BGP Evpn session and check if Evpn routes (multicast, mac, prefix) are exchanged and installed correctly in app-db.
2022-05-24 16:47:09 -05:00
$(DOCKER_FPM_FRR)_DEPENDS += $(FRR) $(FRR_SNMP) $(SWSS) $(LIBYANG2)
Create a docker-swss-layer that holds the swss package. This is to save about 50MB of disk space, since 6 containers individually install this package. Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
2021-11-24 19:00:14 -06:00
$(DOCKER_FPM_FRR)_DBG_DEPENDS = $($(DOCKER_SWSS_LAYER_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) \
Frr 8.2 upgrade (#10691) Why I did it Upgrade FRR to version 8.2.2. Build libyang2 required by FRR. How I did it Update FRR version and tag. How to verify it Following tests were performed on sonic-vs: BGP docker status check BGP configuration and session establishment Route redistribution and ping Issued show commands to check the bgp neighbor and routes Checked app-db to ensure bgp routes are installed with correct interface and nexthop. Create VRF and check FRR knows the VRF Check VRF routes are installed in app-db with correct Vrf name and next-hop Establish BGP Evpn session and check if Evpn routes (multicast, mac, prefix) are exchanged and installed correctly in app-db.
2022-05-24 16:47:09 -05:00
$(FRR_DBG) $(FRR_SNMP_DBG) $(LIBYANG2_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
Create a docker-swss-layer that holds the swss package. This is to save about 50MB of disk space, since 6 containers individually install this package. Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
2021-11-24 19:00:14 -06:00
$(DOCKER_FPM_FRR)_DBG_IMAGE_PACKAGES = $($(DOCKER_SWSS_LAYER_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
Create a docker-swss-layer that holds the swss package. This is to save about 50MB of disk space, since 6 containers individually install this package. Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
2021-11-24 19:00:14 -06:00
$(DOCKER_FPM_FRR)_LOAD_DOCKERS += $(DOCKER_SWSS_LAYER_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