Scripts which perform an installable binary image build for SONiC
Go to file
SuvarnaMeenakshi 9864dfeaa1
[SNMP][IPv6]: Fix SNMP IPv6 reachability issue in certain scenarios (#15487)
Modify snmpd.conf to start snmpd to listen on specific management and loopback ips instead of listening on any ip.

#### Why I did it
SNMP over IPv6 is not working for all scenarios for a single asic platforms.
The expectation is that SNMP query over IPv6 should work over Management or Loopback0 addresses.
**Specific scenario where this issue is seen**
In case of Lab T0 device,  when SNMP request is sent from a directly connected T1 neighbor over Loopback IP, SNMP response was not received.
This was because the SRC IP address in SNMP response was not Loopback IP, it was the PortChannel IP connected to the neighboring device.
```
23:18:51.620897  In 22:26:27:e6:e0:07 ethertype IPv6 (0x86dd), length 105: fc00::72.41725 > **fc00:1::32**.161:  C="msft" **GetRequest**(28)  .1.3.6.1.2.1.1.1.0
23:18:51.621441 Out 28:99:3a:a0:97:30 ethertype IPv6 (0x86dd), length 241: **fc00::71**.161 > fc00::72.41725:  C="msft" **GetResponse**(162)  .1.3.6.1.2.1.1.1.0="SONiC Software Version: SONiC.xxx - HwSku: xx - Distribution: Debian 10.13 - Kernel: 4.19.0-12-2-amd64"
```
In case of IPv4, the SRC IP in SNMP response was correctly set to Loopback IP.
```
23:25:32.769712  In 22:26:27:e6:e0:07 ethertype IPv4 (0x0800), length 85: 10.0.0.57.56701 > **10.1.0.32**.161:  C="msft" **GetRequest**(28)  .1.3.6.1.2.1.1.1.0
23:25:32.975967 Out 28:99:3a:a0:97:30 ethertype IPv4 (0x0800), length 221: **10.1.0.32**.161 > 10.0.0.57.56701:  C="msft" **GetResponse**(162)  .1.3.6.1.2.1.1.1.0="SONiC Software Version: SONiC.xxx - HwSku: xx - Distribution: Debian 10.13 - Kernel: 4.19.0-12-2-amd64"
```

**Sequence of SNMP request and response**
1. SNMP request will be sent with SRC IP fc00::72 DST IP fc00:1::32
2. SNMP request is received at SONiC device is sent to snmpd which is listening on port 161 :::161/
3. snmpd process will parse the request create a response and sent to DST IP fc00::72. 
snmpd process does not track the DST IP on which the SNMP request was received, which in this case is Loopback IP.
snmpd process will only keep track what is tht IP to which the response should be sent to.
4. snmpd process will send the response packet.
5. Kernel will do a route look up on destination IP and find the best path.
ip -6 route get fc00::72
fc00::72 from :: dev PortChannel101 proto kernel src fc00::71 metric 256 pref medium
5. Using the "src" ip from about, the response is sent out. This SRC ip is that of the PortChannel and not the device Loopback IP.

The same issue is seen when SNMP query is sent from a remote server over Management IP.
SONiC device eth0 --------- Remote server
SNMP request comes with SRC IP <Remote_server> DST IP <Mgmt IP>
If kernel finds best route to Remote_server_IP is via BGP neighbors, then it will send the response via front-panel interface with SRC IP as Loopback IP instead of Management IP.

Main issue is that in case of IPv6, snmpd ignores the IP address to which SNMP request was sent, in case of IPv6.
In case of IPv4, snmpd keeps track of DST IP of SNMP request, it will keep track if the SNMP request was sent to mgmt IP or Loopback IP.
Later, this IP is used in ipi_spec_dst as SRC IP which helps kernel to find the route based on DST IP using the right SRC IP.
https://github.com/net-snmp/net-snmp/blob/master/snmplib/transports/snmpUDPBaseDomain.c#L300 
ipi.ipi_spec_dst.s_addr = srcip->s_addr
Reference: https://man7.org/linux/man-pages/man7/ip.7.html
```
If IP_PKTINFO is passed to sendmsg(2)
              and ipi_spec_dst is not zero, then it is used as the local
              source address for the routing table lookup and for
              setting up IP source route options.  When ipi_ifindex is
              not zero, the primary local address of the interface
              specified by the index overwrites ipi_spec_dst for the
              routing table lookup.
```

**This issue is not seen on multi-asic platform, why?**
on multi-asic platform, there exists different network namespaces.
SNMP docker with snmpd process runs on host namespace.
Management interface belongs to host namespace.
Loopback0 is configured on asic namespaces.
Additional inforamtion on how the packet coming over Loopback IP reaches snmpd process running on host namespace: https://github.com/sonic-net/sonic-buildimage/pull/5420
Because of this separation of network namespaces, the route lookup of destination IP is confined to routing table of specific namespace where packet is received.
if packet is received over management interface, SNMP response also is sent out of management interface. Same goes with packet received over Loopback Ip.

##### Work item tracking
- Microsoft ADO **17537063**:

#### How I did it
Have snmpd listen on specific Management and Loopback IPs specifically instead of listening on any IP for single-asic platform.

Before Fix
```
admin@xx:~$ sudo netstat -tulnp | grep 161   
udp        0      0 0.0.0.0:161             0.0.0.0:*                           15631/snmpd         
udp6       0      0 :::161                  :::*                                15631/snmpd  
```
After fix
```
admin@device:~$ sudo netstat -tulnp | grep 161
udp        0      0 10.1.0.32:161           0.0.0.0:*                           215899/snmpd        
udp        0      0 10.3.1.1:161             0.0.0.0:*                           215899/snmpd        
udp6       0      0 fc00:1::32:161          :::*                                215899/snmpd        
udp6       0      0 fc00:2::32:161          :::*                                215899/snmpd  
``` 

**How this change helps with the issue?**
To see snmpd trace logs, modify snmpd to start using the below parameters, in supervisord.conf file
```
/usr/sbin/snmpd -f -LS0-7i -Lf /var/log/snmpd.log
```
When snmpd listens on any IP, snmpd binds to IPv4 and IPv6 sockets as below:
```
netsnmp_udpbase: binding socket: 7 to UDP: [0.0.0.0]:0->[0.0.0.0]:161
trace: netsnmp_udp6_transport_bind(): transports/snmpUDPIPv6Domain.c, 303:
netsnmp_udpbase: binding socket: 8 to UDP/IPv6: [::]:161
```

When IPv4 response is sent, it goes out of fd 7 and IPv6 response goes out of fd 8.
When IPv6 response is sent, it does not have the right SRC IP and it can lead to the issue described.

When snmpd listens on specific Loopback/Management IPs, snmpd binds to different sockets:
```
trace: netsnmp_udpipv4base_transport_bind(): transports/snmpUDPIPv4BaseDomain.c, 207:
netsnmp_udpbase: binding socket: 7 to UDP: [0.0.0.0]:0->[10.250.0.101]:161
trace: netsnmp_udpipv4base_transport_bind(): transports/snmpUDPIPv4BaseDomain.c, 207:
netsnmp_udpbase: binding socket: 8 to UDP: [0.0.0.0]:0->[10.1.0.32]:161
trace: netsnmp_register_agent_nsap(): snmp_agent.c, 1261:
netsnmp_register_agent_nsap: fd 8
netsnmp_udpbase: binding socket: 10 to UDP/IPv6: [fc00:1::32]:161
trace: netsnmp_register_agent_nsap(): snmp_agent.c, 1261:
netsnmp_register_agent_nsap: fd 10
netsnmp_ipv6: fmtaddr: t = (nil), data = 0x7fffed4c85d0, len = 28
trace: netsnmp_udp6_transport_bind(): transports/snmpUDPIPv6Domain.c, 303:
netsnmp_udpbase: binding socket: 9 to UDP/IPv6: [fc00:2::32]:161
```
When SNMP request comes in via Loopback IPv4, SNMP response is sent out of fd 8
```
trace: netsnmp_udpbase_send(): transports/snmpUDPBaseDomain.c, 511:
netsnmp_udp: send 170 bytes from 0x5581f2fbe30a to UDP: [10.0.0.33]:46089->[10.1.0.32]:161 on fd 8
```
When SNMP request comes in via Loopback IPv6, SNMP response is sent out of fd 10
```
netsnmp_ipv6: fmtaddr: t = (nil), data = 0x5581f2fc2ff0, len = 28
trace: netsnmp_udp6_send(): transports/snmpUDPIPv6Domain.c, 164:
netsnmp_udp6: send 170 bytes from 0x5581f2fbe30a to UDP/IPv6: [fc00::42]:43750 on fd 10
```

#### How to verify it
Verified on single asic and multi-asic devices.
Single asic SNMP query with Loopback 
```
ARISTA01T1#bash snmpget -v2c -c xxx 10.1.0.32 1.3.6.1.2.1.1.1.0
SNMPv2-MIB::sysDescr.0 = STRING: SONiC Software Version: SONiC.xx - HwSku: Arista-7260xx - Distribution: Debian 10.13 - Kernel: 4.19.0-12-2-amd64
ARISTA01T1#bash snmpget -v2c -c xxx fc00:1::32 1.3.6.1.2.1.1.1.0
SNMPv2-MIB::sysDescr.0 = STRING: SONiC Software Version: SONiC.xx - HwSku: Arista-7260xxx - Distribution: Debian 10.13 - Kernel: 4.19.0-12-2-amd64
```

On multi-asic -- no change.
```
sudo netstat -tulnp | grep 161
udp        0      0 0.0.0.0:161             0.0.0.0:*                           17978/snmpd         
udp6       0      0 :::161                  :::*                                17978/snmpd 
```
Query result using Loopback IP from a directly connected BGP neighbor
```
ARISTA01T2#bash snmpget -v2c -c xxx 10.1.0.32 1.3.6.1.2.1.1.1.0
SNMPv2-MIB::sysDescr.0 = STRING: SONiC Software Version: SONiC.xx - HwSku: xx - Distribution: Debian 9.13 - Kernel: 4.9.0-14-2-amd64
ARISTA01T2#bash snmpget -v2c -c xxx fc00:1::32 1.3.6.1.2.1.1.1.0
SNMPv2-MIB::sysDescr.0 = STRING: SONiC Software Version: SONiC.xx - HwSku: xx - Distribution: Debian 9.13 - Kernel: 4.9.0-14-2-amd64  
```
<!--
If PR needs to be backported, then the PR must be tested against the base branch and the earliest backport release branch and provide tested image version on these two branches. For example, if the PR is requested for master, 202211 and 202012, then the requester needs to provide test results on master and 202012.
-->
2023-07-12 09:52:06 -07:00
.azure-pipelines Refine PR test template format (#15636) 2023-07-10 10:47:40 +08:00
.github [action] Fix auto merge workflow commit message. (#15450) 2023-06-19 08:31:56 +08:00
device [docker-sonic-vs]: More changes to support DPU-2P HWKSU (#15695) 2023-07-11 09:57:50 -07:00
dockers [SNMP][IPv6]: Fix SNMP IPv6 reachability issue in certain scenarios (#15487) 2023-07-12 09:52:06 -07:00
files Support Reset factory (#14105) 2023-07-11 16:14:17 -07:00
installer Add support for secure upgrade (#11862) 2023-06-26 12:04:40 +03:00
platform [docker-sonic-vs]: More changes to support DPU-2P HWKSU (#15695) 2023-07-11 09:57:50 -07:00
rules Pick dependency files in submodules. (#15142) 2023-07-11 14:32:08 -07:00
scripts Add support for secure upgrade (#11862) 2023-06-26 12:04:40 +03:00
sonic-slave-bullseye Update the docker daemon to 24.0.2 (#15652) 2023-07-06 14:44:29 -07:00
sonic-slave-buster Update the docker daemon to 24.0.2 (#15652) 2023-07-06 14:44:29 -07:00
sonic-slave-jessie Update golang version for telemetry build in sonic-slave-buster to fix (#14636) 2023-04-16 23:44:11 -07:00
sonic-slave-stretch [CI][doc][build] Trim script and sonic-slave-* folders files trailing blanks (#15161) 2023-05-24 09:25:12 -07:00
src [submodule] Update submodule sonic-linux-kernel to the latest HEAD automatically (#15782) 2023-07-12 16:37:25 +08:00
.artifactignore [ci] Archive compiled Debian packages and Python wheels (#6650) 2021-02-02 23:42:03 -08:00
.gitignore [build] Do not ignore well-known debian files (#14565) 2023-04-12 09:10:22 -07:00
.gitmodules [dash-api]: Add dash-api and related protobuf library (#14515) 2023-07-05 09:59:35 -07:00
azure-pipelines.yml Refine PR test template format (#15636) 2023-07-10 10:47:40 +08:00
build_debian.sh Support Reset factory (#14105) 2023-07-11 16:14:17 -07:00
build_debug_docker_j2.sh [sonic-buildimage] Fix build issue for docker-dhcp-relay-dbg.gz. Issue (#4136) 2020-02-10 17:16:42 -08:00
build_docker.sh [Build] use pigz to speed up a build (#12825) 2022-12-17 14:38:31 -08:00
build_image.sh Add support for secure upgrade (#11862) 2023-06-26 12:04:40 +03:00
check_install.py Add California-SB237 feature. Requires to change default user password (#12678) 2023-02-23 15:36:37 -08:00
functions.sh [build] fix CI warnings issued by "git describe" (#13098) 2023-01-03 10:04:31 -08:00
get_docker-base.sh Add mkdir if the target dir does not exist (#130) 2016-12-16 02:19:15 +00:00
install_sonic.py [build] Increase timeout value when installing SONiC image on kvm (#11191) 2022-07-20 08:13:28 +08:00
LICENSE updating readme, formatting in license 2016-03-09 17:39:34 +00:00
MAINTAINERS Adding license and maintainers 2016-03-08 19:10:18 -08:00
Makefile [build] Add retry when make SONiC image to improve success rate. (#12325) 2022-12-19 12:18:36 +08:00
Makefile.cache [Build] Update SLAVE_BASE_TAG and DPKG cache if Debian mirrors were changed (#12702) 2022-11-15 13:02:34 +08:00
Makefile.work [ci] Remove debian mirror timestamp from sonic slave base tag (#15189) 2023-05-24 09:22:12 -07:00
onie-image-arm64.conf [build]: increase raw image disk size to 4GB (#12958) 2022-12-06 23:37:05 -08:00
onie-image-armhf.conf [build]: increase raw image disk size to 4GB (#12958) 2022-12-06 23:37:05 -08:00
onie-image.conf [build]: increase raw image disk size to 4GB (#12958) 2022-12-06 23:37:05 -08:00
onie-mk-demo.sh Add support for secure upgrade (#11862) 2023-06-26 12:04:40 +03:00
push_docker.sh [ci] Support multi tags when pushing docker image (#10771) 2022-05-09 16:43:21 +08:00
README.buildsystem.md [docs] Correct clone instructions & typos (#12733) 2022-11-18 15:00:16 +08:00
README.md Add the release 202211/202203 in the README.md (#15593) 2023-06-26 10:23:49 -07:00
slave.mk Add SECURE_UPGRADE_PROD_TOOL_ARGS flag to make it possible for vendors to pass their own arguments on the prod signing script (#14581) 2023-05-16 08:36:13 +03:00
ThirdPartyLicenses.txt [TACACS+] Add Bash TACACS+ plugin for per-command authorization. (#8715) 2021-11-13 09:57:30 +08:00
update_screen.sh [build]: Added support for cache status on the build output (#5564) 2020-10-09 02:49:20 -07:00

master builds:

Barefoot Broadcom Centec Centec(arm64) Innovium Mellanox Marvell(armhf) Marvell(arm64) Nephos VS

202305 builds:

Barefoot Broadcom Centec Centec(arm64) Innovium Mellanox Marvell(armhf) Nephos VS

202211 builds:

Barefoot Broadcom Centec Centec(arm64) Innovium Mellanox Marvell(armhf) Nephos VS

202205 builds:

Barefoot Broadcom Centec Centec(arm64) Innovium Mellanox Marvell(armhf) Nephos VS

202111 builds:

Barefoot Broadcom Centec Centec(arm64) Innovium Mellanox Marvell(armhf) Nephos VS

202012 builds:

Barefoot Broadcom Centec Centec(arm64) Innovium Marvell(armhf) Mellanox Nephos VS

201911 builds:

Barefoot Broadcom Innovium Mellanox Nephos VS

201811 builds:

Broadcom Mellanox Innovium Nephos VS

sonic-buildimage

Build SONiC Switch Images

Description

Following are the instructions on how to build an (ONIE) compatible network operating system (NOS) installer image for network switches, and also how to build docker images running inside the NOS. Note that SONiC images are build per ASIC platform. Switches using the same ASIC platform share a common image. For a list of supported switches and ASIC, please refer to this list

Hardware

Any server can be a build image server as long as it has:

  • Multiple cores to increase build speed
  • Plenty of RAM (less than 8 GiB is likely to cause issues)
  • 300G of free disk space
  • KVM Virtualization Support.

Note: If you are in a VM, make sure you have support for nested virtualization. Some cases (e.g. building OVS image) also requires extra configuration options to expose the full KVM interface to the VM (e.g. the KVM paravirtualization support on VirtualBox).

A good choice of OS for building SONiC is currently Ubuntu 20.04.

Prerequisites

  • Install pip and jinja in host build machine, execute below commands if j2/j2cli is not available:
sudo apt install -y python3-pip
pip3 install --user j2cli
  • Install Docker and configure your system to allow running the 'docker' command without 'sudo':
    • Add current user to the docker group: sudo gpasswd -a ${USER} docker
    • Log out and log back in so that your group membership is re-evaluated

Note: If a previous installation of Docker using snap was present on the system, remove it and also remove docker from snap before reinstallating docker. This will avoid known bugs that falsely report read-only filesystems issues during the build process.

Clone the repository with all the git submodules

To clone the code repository recursively:

git clone --recurse-submodules https://github.com/sonic-net/sonic-buildimage.git

Usage

To build SONiC installer image and docker images, run the following commands:

# Ensure the 'overlay' module is loaded on your development system
sudo modprobe overlay

# Enter the source directory
cd sonic-buildimage

# (Optional) Checkout a specific branch. By default, it uses master branch.
# For example, to checkout the branch 201911, use "git checkout 201911"
git checkout [branch_name]

# Execute make init once after cloning the repo,
# or after fetching remote repo with submodule updates
make init

# Execute make configure once to configure ASIC
make configure PLATFORM=[ASIC_VENDOR]

# Build SONiC image with 4 jobs in parallel.
# Note: You can set this higher, but 4 is a good number for most cases
#       and is well-tested.
make SONIC_BUILD_JOBS=4 all

The supported ASIC vendors are:

  • PLATFORM=barefoot
  • PLATFORM=broadcom
  • PLATFORM=marvell
  • PLATFORM=mellanox
  • PLATFORM=cavium
  • PLATFORM=centec
  • PLATFORM=nephos
  • PLATFORM=innovium
  • PLATFORM=vs

Usage for ARM Architecture

ARM build has dependency in docker version 18. If docker version is 19, downgrade to 18 with:

sudo apt-get install --allow-downgrades -y docker-ce=5:18.09.0~3-0~ubuntu-xenial
sudo apt-get install --allow-downgrades -y docker-ce-cli=5:18.09.0~3-0~ubuntu-xenial

To build Arm32 bit for (ARMHF) platform

# Execute make configure once to configure ASIC and ARCH
make configure PLATFORM=[ASIC_VENDOR] PLATFORM_ARCH=armhf
make target/sonic-[ASIC_VENDER]-armhf.bin

example:

make configure PLATFORM=marvell-armhf PLATFORM_ARCH=armhf
make target/sonic-marvell-armhf.bin

To build Arm32 bit for (ARMHF) Marvell platform on amd64 host for debian buster using cross-compilation, run the following commands:

# Execute make configure once to configure ASIC and ARCH for cross-compilation build

NOJESSIE=1 NOSTRETCH=1 BLDENV=buster CROSS_BLDENV=1 \
make configure PLATFORM=marvell-armhf PLATFORM_ARCH=armhf

# Execute Arm32 build using cross-compilation environment

NOJESSIE=1 NOSTRETCH=1 BLDENV=buster CROSS_BLDENV=1 make target/sonic-marvell-armhf.bin

Running the above Arm32 build using cross-compilation instead of qemu emulator drastically reduces the build time.

To build Arm64 bit for platform

# Execute make configure once to configure ASIC and ARCH

make configure PLATFORM=[ASIC_VENDOR] PLATFORM_ARCH=arm64

# example:

make configure PLATFORM=marvell-arm64 PLATFORM_ARCH=arm64

NOTE:

  • Recommend reserving at least 100G free space to build one platform with a single job. The build process will use more disk if you are setting SONIC_BUILD_JOBS to more than 1.

  • If Docker's workspace folder, /var/lib/docker, resides on a partition without sufficient free space, you may encounter an error like the following during a Docker container build job:

    /usr/bin/tar: /path/to/sonic-buildimage/<some_file>: Cannot write: No space left on device

    The solution is to move the directory to a partition with more free space.

  • Use http_proxy=[your_proxy] https_proxy=[your_proxy] no_proxy=[your_no_proxy] make to enable http(s) proxy in the build process.

  • Add your user account to docker group and use your user account to make. root or sudo are not supported.

The SONiC installer contains all docker images needed. SONiC uses one image for all devices of a same ASIC vendor.

For Broadcom ASIC, we build ONIE and EOS image. EOS image is used for Arista devices, ONIE image is used for all other Broadcom ASIC based devices.

make configure PLATFORM=broadcom
# build debian stretch required targets
BLDENV=stretch make stretch
# build ONIE image
make target/sonic-broadcom.bin
# build EOS image
make target/sonic-aboot-broadcom.swi

You may find the rules/config file useful. It contains configuration options for the build process, like adding more verbosity or showing dependencies, username and password for base image etc.

Every docker image is built and saved to target/ directory. So, for instance, to build only docker-database, execute:

make target/docker-database.gz

Same goes for debian packages, which are under target/debs/:

make target/debs/swss_1.0.0_amd64.deb

Every target has a clean target, so in order to clean swss, execute:

make target/debs/swss_1.0.0_amd64.deb-clean

It is recommended to use clean targets to clean all packages that are built together, like dev packages for instance. In order to be more familiar with build process and make some changes to it, it is recommended to read this short Documentation.

Build debug dockers and debug SONiC installer image

SONiC build system supports building dockers and ONIE-image with debug tools and debug symbols, to help with live & core debugging. For details refer to SONiC Buildimage Guide.

SAI Version

Please refer to SONiC roadmap on the SAI version for each SONiC release.

Notes

  • If you are running make for the first time, a sonic-slave-${USER} docker image will be built automatically. This may take a while, but it is a one-time action, so please be patient.
  • The root user account is disabled. However, the created user can sudo.
  • The target directory is ./target, containing the NOS installer image and docker images.
    • sonic-generic.bin: SONiC switch installer image (ONIE compatible)
    • sonic-aboot.bin: SONiC switch installer image (Aboot compatible)
    • docker-base.gz: base docker image where other docker images are built from, only used in build process (gzip tar archive)
    • docker-database.gz: docker image for in-memory key-value store, used as inter-process communication (gzip tar archive)
    • docker-fpm.gz: docker image for quagga with fpm module enabled (gzip tar archive)
    • docker-orchagent.gz: docker image for SWitch State Service (SWSS) (gzip tar archive)
    • docker-syncd-brcm.gz: docker image for the daemon to sync database and Broadcom switch ASIC (gzip tar archive)
    • docker-syncd-cavm.gz: docker image for the daemon to sync database and Cavium switch ASIC (gzip tar archive)
    • docker-syncd-mlnx.gz: docker image for the daemon to sync database and Mellanox switch ASIC (gzip tar archive)
    • docker-syncd-nephos.gz: docker image for the daemon to sync database and Nephos switch ASIC (gzip tar archive)
    • docker-syncd-invm.gz: docker image for the daemon to sync database and Innovium switch ASIC (gzip tar archive)
    • docker-sonic-p4.gz: docker image for all-in-one for p4 software switch (gzip tar archive)
    • docker-sonic-vs.gz: docker image for all-in-one for software virtual switch (gzip tar archive)
    • docker-sonic-mgmt.gz: docker image for managing, configuring and monitoring SONiC (gzip tar archive)

Contribution Guide

All contributors must sign a contribution license agreement before contributions can be accepted. Visit EasyCLA - Linux Foundation.

GitHub Workflow

We're following basic GitHub Flow. If you have no idea what we're talking about, check out GitHub's official guide. Note that merge is only performed by the repository maintainer.

Guide for performing commits:

  • Isolate each commit to one component/bugfix/issue/feature
  • Use a standard commit message format:

[component/folder touched]: Description intent of your changes

[List of changes]

Signed-off-by: Your Name your@email.com

For example:

swss-common: Stabilize the ConsumerTable

  • Fixing autoreconf
  • Fixing unit-tests by adding checkers and initialize the DB before start
  • Adding the ability to select from multiple channels
  • Health-Monitor - The idea of the patch is that if something went wrong with the notification channel, we will have the option to know about it (Query the LLEN table length).

Signed-off-by: user@dev.null

  • Each developer should fork this repository and add the team as a Contributor
  • Push your changes to your private fork and do "pull-request" to this repository
  • Use a pull request to do code review
  • Use issues to keep track of what is going on

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.