#### Why I did it
The debian install files are required for installing sonic_platform packages
#### How I did it
Add install files to under debian folder
Co-authored-by: robert.hong <robert.hong@qct.io>
- Why I did it
The methods get_model, get_serial, and get_revision have been implemented by reading relevant information from VPD and then recording the information into relevant fields.
However, there is no VPD data on platforms with fixed PSUs and relevant fields haven't been initialized, which causes the methods to throw exceptions. which in turn prevents psud from inserting fields into PSU table.
Eventually, this causes show platform psustatus doesn't output correct info.
- How I did it
Initialize those fields as N/A on systems with fixed PSUs.
- How to verify it
Manually test.
Signed-off-by: Stephen Sun <stephens@nvidia.com>
vs has components from swss, bgp, teamd and nat. This table is needed by this change https://github.com/Azure/sonic-utilities/pull/1554.
Because Azure/sonic-utilities#1554 requires "config warm_restart enable FEATURE" and the FEATURE has to be in feature table.
Signed-off-by: Stepan Blyschak <stepanb@nvidia.com>
Why I did it
Quagga is no longer being used. Remove quagga-related code (e.g., docker-fpm-quagga, sonic-quagga, etc.).
How I did it
Remove quagga-related code.
#### Why I did it
- To build flashrom properly with dependency tracking.
#### How I did it
- Moved flashrom code from platform/broadcom/sonic-platform-modules-dell/tools directory to src/flashrom directory.
- At the end, flashrom_0.9.7_amd64.deb package is build which will be installed in the devices.
- Currently flashrom builds only for Dell S6100 platforms.
Introduce new sonic-buildimage images for Broadcom DNX ASIC family.
sonic-broadcom-dnx.bin
sonic-aboot-broadcom-dnx.swi
How I did it
NO CHANGE to existing make commands
make init; make configure PLATFORM=broadcom; make target/sonic-aboot-broadcom.swi; make target/sonic-broadcom.bin
The difference now is that it will result in new broadcom images for DNX asic family as well.
sonic-broadcom.bin, sonic-broadcom-dnx.bin
sonic-aboot-broadcom.swi, sonic-aboot-broadcom-dnx.swi
Note: This PR also adds support for Broadcom SAI 5.0 (based on 1.8 SAI ) for DNX based platform + changes in platform x86_64-arista_7280cr3_32p4 bcm config files and platform_env.conf files
#### Why I did it
Following the discussion in another PR https://github.com/Azure/sonic-buildimage/pull/7708#discussion_r642933510 , since there will be multi subfolders under **/var/log/mellanox**, so we agreed to only mount this folder and the subfolders will be created afterward on demand.
#### How I did it
during the syncd docker creation, only mount folder **/var/log/mellanox**
#### How to verify it
build an Mellanox image and verify the related folder on the host and docker side.
#### Why I did it
Failures observed when running the open community platform test suite (sonic-mgmt)
#### How I did it
Call PSUBase class initializer from derived class
Signed-off-by: Arthi Sivanantham arthi_sivanantham@dell.com
Why I did it
SONiC YANG model support for AAA and TACACS features.
How I did it
Defined various AAA and TACACS YANG containers and lists based on config-DB schema.
How to verify it
Successful build of the following packages:
make target/python-wheels/sonic_yang_models-1.0-py3-none-any.whl
make target/python-wheels/sonic_yang_mgmt-1.0-py3-none-any.whl
#### Why I did it
Create a target for delayed service timers. Few services in sonic have delayed to speed up the bring up of the system and essential services. However there is no way to track when they start. This will be a problem when executing config reload as config reload expects all services to be up. Hence grouped all the timers that trigger the delayed services under one target so that they could be tracked in 'config reload' command
#### How I did it
Created delay.target service and add created dependency on the delayed targets.
Add device and platform code for ix7-bwde, ix8a-bwde.
Support platform API 2.0 for all quanta platforms except for ix1b
Co-authored-by: robert.hong <robert.hong@qct.io>
- Why I did it
To create SDK dump on Mellanox devices when SDK event has occurred.
- How I did it
Set the SKUs keys needed to initialize the feature in SAI.
- How to verify it
Simulate SDK event and check that dump is created in the expected path.
#### Why I did it
while sonic upgrade, Image will be extracted to tmpfs for installation so tmpfs size should be larger than image size. Image installation will fail if image size is larger than tmpfs size.
we are facing below error while installing debug image with size greater than tmpfs which is 1.5g in marvell armhf platform.
sonic-installer install <url>
New image will be installed, continue? [y/N]: y
Downloading image...
...99%, 1744 MB, 708 KB/s, 0 seconds left...
Installing image SONiC-OS-202012.0-dirty-20210311.224845 and setting it as default...
Command: bash /tmp/sonic_image
tar: installer/fs.zip: Wrote only 7680 of 10240 bytes
tar: installer/onie-image-arm64.conf: Cannot write: No space left on device
tar: Exiting with failure status due to previous errors
Verifying image checksum ... OK.
Preparing image archive ...
#### How I did it
compare downloaded image size with tmpfs size, if size less than image size update the tmpfs size according to image size.
#### How to verify it
Install an Image with size larger than tmpfs. we verified by installing debug image with size 1.9gb which is larger than tmpfs size 1.5gb.
Update sonic-utilities submodule. This include the following commits:
285960d [config]: Update environment file during config reload (#1673)
3f0ecd5 [config] Remove "reset failed" print lines from config reload (#1654)
a1c8751 Make the soft-reboot available in the SONiC image on master (#1681)
45e7b71 [Mellanox] Add all results from saisdkdump to the techsupport on Mellanox switches (#1660)
- Why I did it
The default breakout mode according to hwsku.json for the MSN4410 is 1x400G and this is not a supported breakout mode according to its platform.json
This causes a conflict on boot of this platform and no containers on the switch will init successfully.
- How I did it
Referenced the platform specification files and updated platform.json
- How to verify it
Install master version of SONiC on MSN4410
Boot switch and verify swss is successfully running using docker ps
- Why I did it
Remove EEPROM cache file and use DB instead
- How I did it
Read EEPROM data from DB if possible
If data is not ready in DB, read from hardware using a visitor pattern
- How to verify it
Manual test and regression
Why I did it
There is a regression on 2700 platform where the evidence points to the flex counter change.
How I did it
Back track the swss submodule head to exclude:
[flex-counters] Delay flex counters stats init for faster boot time (#1749)
Verified that image build from this PR doesn't trigger the crash.
Signed-off-by: Ying Xie ying.xie@microsoft.com
7670b49 [sonic_platform/sfp_base] Add common definition for get SFP error status (#194)
1336598 [CI] sonic-config-engine now depends on SONiC YANG packages (#198)
f57fee4 Add to check pcie configuration revision to get the right configuration. (#195)
4e3a0a0 Fix typo for midplane APIs. (#196)
fc2e9e2 [eeprom_tlv_info] Optimize EEPROM data process by using visitor pattern (#193)
Why I did it
SONiC YANG model support for BGP & route-map features.
How I did it
Defined various BGP and route-map YANG containers and lists based on config-DB schema.
How to verify it
Built the following successfully with various BGP & route-map unit test cases.
make target/python-wheels/sonic_yang_models-1.0-py3-none-any.whl
make target/python-wheels/sonic_yang_mgmt-1.0-py3-none-any.whl
Updates sonic-platform-daemons submodule. Includes the following commits:
```
eb8a223 [xcvrd] Force cleanup of chassis global variable on deinit (#193)
a6903c0 [CI] sonic-config-engine now depends on SONiC YANG packages (#194)
bf60a27 Replace swsssdk.SonicV2Connector with swsscommon implementation (#191)
```
19615e3 Fixing db_migrator for Feature table (#1674)
d1c1c61 [tests]: skip some dynamic port breakout unit tests (#1677)
25669c3 [CI] sonic-config-engine now depends on SONiC YANG packages (#1675)
3ff68c4 [neighbor-advertiser] delete the tunnel maps appropriately (#1663)
a425ca2 [config] support for configuring muxcable to manual mode of operation (#1642)
25e17de [show platform summary] Add chassis hardware info to platform summary and version (#1624)
f5f2a00 [db_migrator] fix old 1911 feature config migration to a new one. (#1635)
56db162 [config] Fix config int add incorrect ip (#1414)
1da879c [db_migrator][Mellanox] Update Mellanox buffer migrator with 2km-cable supported (#1564)
c2b760f [sonic_package_manager] flush once finished saving docker image into temporary file (#1638)
cd69473 Replace swsssdk.ConfigDBConnector and SonicDBConfig with swsscommon implementation (#1620)
5f20365 Change to use rvtysh when calling the show commands (#1572)
51d6bf5 Fix Aboot breakage in sonic package manager in sonic-installer (#1625)
18bed46 [console][show] Force refresh all lines status during show line (#1641)
b616cd9 [TPID CONFIG] Added TPID configuration CLI support (#1618)
01eb4b1 [show] support for show muxcable firmware version of only active banks (#1629)
7744c8d [fdb]cli: fdb entries are cleared according to vlan or port or vlan&&port (#657)
e23c5ee Add psu hardware revision to psushow table (#1601)
f1726fe Make advance_version_for_expected_database available for other db migrator test cases as well (#1614)
5d1ad05 [show] add support for muxcable metrics (#1615)
feeab29 [config] Sort Config Db When Saving (#1623)
#### Why I did it
To allow SSH connections from IPv6 addresses
Resolves https://github.com/Azure/sonic-buildimage/issues/7668
#### How I did it
In build_debian.sh, modify sshd_config file so as to enable listening for IPv6 connections
#### Why I did it
Recently, the build started failing with messages like
```
2021-06-16T16:55:02.8675603Z tests/hostcfgd/hostcfgd_test.py:5: in <module>
2021-06-16T16:55:02.8676208Z from parameterized import parameterized
2021-06-16T16:55:02.8677145Z E ModuleNotFoundError: No module named 'parameterized'
```
Unit tests for hostcfgd depend on the `parameterized` Python package, but it was never added as a dependency to the setup.py file. This dependency was added ~3 months ago. I'm not sure why we only started seeing this failure recently.
#### How I did it
Add 'parameterized' package as a test dependency in setup.py for sonic-host-services package
Why I did it
Support multiple pcie configuration file and change the pcie status table name
This is to match with below two PRs.
Azure/sonic-platform-common#195Azure/sonic-platform-daemons#189
How I did it
Check pcie configuration file with wild card and change the device status table name
How to verify it
Restart with changes and see if the pcie check works as expected.
Why I did it
The Mellanox platform is required to support the fwutil auto-update feature defined here
This is to allow switches, when performing SONiC upgrades to choose whether to perform firmware upgrades that may interrupt the data plane through a cold boot.
How I did it
Two methods were added to the component implementations for mellanox.
In the base Component class we add a default function that chooses to skip the installation of any firmware unless the cold boot option is provided. This is because the Mellanox platform, by default, does not support installing firmware on ONIE, the CPLD, or the BIOS "on-the-fly".
In the ComponentSSD class we add a function that behaves similarly but uses the Mellanox specific SSD firmware upgrade tool to check if the current SSD supports being upgraded on the fly in order to decide whether to skip or perform the installation.
How to verify it
Unit tests are included with this PR. These test will run on build of target sonic-mellanox.bin
You may also perform fwutil auto-update ... commands after Azure/sonic-utilities#1242 is merged in.
UserID is different with the image built by Jenkins if we build docker-sonic-mgmt in sonicbld pool.
So we build this image in sonictest pool. There is a sonictmp user with UserID 1001.
This will make docker image same as the image built in Jenkins
Why I did it
The SONiC switches get their docker images from local repo, populated during install with container images pre-built into SONiC FW. With the introduction of kubernetes, new docker images available in remote repo could be deployed. This requires dockerd to be able to pull images from remote repo.
Depending on the Switch network domain & config, it may or may not be able to reach the remote repo. In the case where remote repo is unreachable, we could potentially make Kubernetes server to also act as http-proxy.
How I did it
When admin explicitly enables, the kubernetes-server could be configured as docker-proxy. But any update to docker-proxy has to be via service-conf file environment variable, implying a "service restart docker" is required. But restart of dockerd is vey expensive, as it would restarts all dockers, including database docker.
To avoid dockerd restart, pre-configure an http_proxy using an unused IP. When k8s server is enabled to act as http-proxy, an IP table entry would be created to direct all traffic to the configured-unused-proxy-ip to the kubernetes-master IP. This way any update to Kubernetes master config would be just manipulating IPTables, which will be transparent to all modules, until dockerd needs to download from remote repo.
How to verify it
Configure a switch such that image repo is unreachable
Pre-configure dockerd with http_proxy.conf using an unused IP (e.g. 172.16.1.1)
Update ctrmgrd.service to invoke ctrmgrd.py with "-p" option.
Configure a k8s server, and deploy an image for feature with set_owner="kube"
Check if switch could successfully download the image or not.
What I did:
Updated 7260 MMU Profile based on latest MSFT Tier 1 Tomahawk2_MMU_Setting_48x100G_40m_16x100G_300m_v1.0 and
TH2_PGHdrm_MSFT.
How I verify:
Made sure image is up/traffic is flowing/mmu dump looked fine.
SAI qos test need will be updated to support this SKU.
#### Why I did it
The PR checkers do not re-run the sonic-config-engine test cases, caused by some of the config files changes not detected.
https://sonic-jenkins.westus2.cloudapp.azure.com/job/mellanox/job/buildimage-mlnx-all/660/console
…
07:13:24 ======================================================================
07:13:24 ERROR: test_bgpd_quagga (tests.test_j2files.TestJ2Files)
07:13:24 ----------------------------------------------------------------------
…
07:13:24 ======================================================================
07:13:24 ERROR: test_zebra_quagga (tests.test_j2files.TestJ2Files)
07:13:24 ----------------------------------------------------------------------
…
07:13:24 error: Test failed: <unittest.runner.TextTestResult run=161 errors=2 failures=0>
07:13:24 [ FAIL LOG END ] [ target/python-wheels/sonic_config_engine-1.0-py2-none-any.whl ]
07:13:24 make: *** [slave.mk:603: target/python-wheels/sonic_config_engine-1.0-py2-none-any.whl] Error 1
07:13:24 Makefile.work:292: recipe for target 'target/sonic-mellanox.bin' failed
07:13:24 make[1]: *** [target/sonic-mellanox.bin] Error 2
07:13:24 make[1]: Leaving directory '/data2/johnar/workspace/mellanox/buildimage-mlnx-all'
07:13:24 Makefile:7: recipe for target 'target/sonic-mellanox.bin' failed
07:13:24 make: *** [target/sonic-mellanox.bin] Error 2
See PR: https://github.com/Azure/sonic-buildimage/pull/7476
#### How I did it
Add the depended files.
See src/sonic-config-engine/tests/test_j2files.py
Signed-off-by: Mykola Gerasymenko <mykolax.gerasymenko@intel.com>
Why I did it
Dynamic Port Breakout falls cause of PG_DROP yang model missing
How I did it
Add PG_DROP yang model and add check this field in unit test for yang model
How to verify it
Firstly try to do DPB (2x50G) for Ethernet0 port:
sudo config interface breakout Ethernet0 2x50G -f
After that try to do DPB (1x100G[40G]) for Ethernet0 port:
sudo config interface breakout Ethernet0 1x100G[40G] -f
Both commands should work correctly.
- Why I did it
Enhance the Python3 support for platform API. Originally, some platform APIs call SDK API which didn't support Python 3. Now the Python 3 APIs have been supported in SDK 4.4.3XXX, Python3 is completely supported by platform API
- How I did it
Start all platform daemons from python3
1. Remove #/usr/bin/env python at the beginning of each platform API file as the platform API won't be started as daemons but be imported from other daemons.
2. Adjust SDK API calls accordingly
- How to verify it
Manually test and run regression platform test
Signed-off-by: Stephen Sun <stephens@nvidia.com>
