Co-authored-by: Arun LK <Arun_L_K@dell.com>
Why I did it
Support for show system-health command in s5232f
How I did it
Added the configuration, API changes to support system health
How to verify it
Execute "show system-health summary/detail/monitor-list" CLI.
Signed-off-by: Rajkumar Pennadam Ramamoorthy rpennadamram@marvell.com
Why I did it
Install sonic image from ONIE. Once system is up, execute "config reload" command.
Root cause is that "determine-reboot-cause.service" was in failed state.
root@sonic:/host/reboot-cause# systemctl list-units --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● determine-reboot-cause.service loaded failed failed Reboot cause determination service
How I did it
Fixed the issue by setting default reason to "REBOOT_CAUSE_UNKNOWN" instead of "None".
How to verify it
Check " determine-reboot-cause.service' loaded successfully post image installation from ONIE.
Verify "reboot-cause.txt" file is created and config reload succeeds.
Use DOCKER_HOST. Every client including docker command and python docker API uses this environment variable to connect to dockerd.
Signed-off-by: Stepan Blyschak <stepanb@nvidia.com>
#### Why I did it
hostcfgd is starting at the same time as 'create_switch' method is called on orchagent process.
This introduce a degradation on the function execution time which eventually cause the fast-boot flow and a boot scenarion in general to run slower (~6 seconds).
This change will delay the start time of this daemon.
The aaastatsd will delay as well since it has a dependency on hostcfgd, so it is required to delay both.
90 seconds determined as the maximum allowed downtime for control plane to come back up on fast-boot flow.
#### How I did it
Add two timers for hostcfgd and aaastatsd services in order to delay the startup of these services.
#### How to verify it
Install an image with this change and observe the daemons start 90 seconds after the system boot.
This PR updates the following commits
cd3cca7 [Y-Cable][Credo] Credo implementation of YCable class which inherits from YCableBase required for Y-Cable API's in sonic-platform-daemons (#203)
bd694b2 Load interval from thermal_policy.json (#178)
c43dc17 [sonic_y_cable] add abstract class YCableBase required for Y-cable API support for multiple vendors (#186)
Signed-off-by: vaibhav-dahiya <vdahiya@microsoft.com>
the branch refers the branch name that the commit is in,
for example master, 202012, 201911, ...
In case there is no branch, the name will be HEAD.
release is encoded in /etc/sonic/sonic_release file.
the file is only available for a release branch.
It is not available in master branch.
example for master branch
```
build_version: 'master.602-6efc0a88'
debian_version: '10.7'
kernel_version: '4.19.0-9-2-amd64'
asic_type: vs
commit_id: '6efc0a88'
branch: 'master'
release: 'none'
build_date: Tue Dec 29 06:54:02 UTC 2020
build_number: 602
built_by: johnar@jenkins-worker-23
```
example for 202012 release branch
```
build_version: '202012.602-6efc0a88'
debian_version: '10.7'
kernel_version: '4.19.0-9-2-amd64'
asic_type: vs
commit_id: '6efc0a88'
branch: '202012'
release: '202012'
build_date: Tue Dec 29 06:54:02 UTC 2020
build_number: 602
built_by: johnar@jenkins-worker-23
```
Signed-off-by: Guohan Lu <lguohan@gmail.com>
#### Why I did it
* `arp_update` fails to ping those neighbors over vlan sub interfaces.
#### How I did it
* modify `arp_update_vars.j2` to get vlan sub interfaces with ipv6 addresses assigned.
* modify `arp_update` to send ipv6 pings over those retrieved vlan sub interfaces.
Signed-off-by: Longxiang Lyu <lolv@microsoft.com>
* Update default cable len to 0m for TD2 (#8298)
* Update sonic-cfggen tests with the correct cable len
Signed-off-by: Neetha John <nejo@microsoft.com>
As part of the buffer reclamation efforts for TD2, setting the default cable len to 0m which means unused ports will have a cable len of 0m.
Why I did it
To align with the changes in Azure/sonic-swss#1830
How to verify it
- With the default cable len set to 0m and the associated changes in swss, CABLE_LENGTH table had '0m' set for unused ports and accordingly more space was reserved for the shared pool
- Cfggen tests passed with the cable len update
#### Why I did it
Remove the call to `SonicDBConfig.load_sonic_global_db_config()` in the multi asic functions.
The expection is the client calling this function will call `SonicDBConfig.load_sonic_global_db_config()`
This PR is dependent on the PR https://github.com/Azure/sonic-utilities/pull/1712
#### How to verify it
compile sonic-utilities
Why I did it
platform test suite failed for few API's in DellEMC Z9332f platform.
How I did it
Modified the API's to return the expected values in the script.
How to verify it
Run platform test suite after making the changes.
This PR contains the following commits:
54b74a2 2021-08-04 [LLDP] Fix lldpshow script to enable display multiple MAC addresses on the same remote physical interface (#1657)
0d53b7a 2021-08-03 [sonic_installer] don't print errors when installing an image not supporting app ext (#1719)
394e2fb 2021-08-03 Implement script null_route_helper (#1737)
dd01b56 2021-08-02 disk_check updates: (#1736)
8a74d03 2021-07-30 [CLI][show][bgp] Fix the show ip bgp network command (#1733)
679a4ba 2021-07-30 [MACsec]: Allow upgrade-docker for macsec container (#1716)
e9c73e8 2021-07-28 [CLI][MPLS][Show] Added multi ASIC support for 'show mpls command'.
Signed-off-by: Basim Shalata <basims@nvidia.com>
This PR is to update sonic-utilities for master branch
Changes including
```
54b74a2 [LLDP] Fix lldpshow script to enable display multiple MAC addresses on the same remote physical interface (#1657)
0d53b7a [sonic_installer] don't print errors when installing an image not supporting app ext (#1719)
394e2fb Implement script null_route_helper (#1737)
```
Signed-off-by: bingwang <bingwang@microsoft.com>
Why I did it
To support "pcied" and "pcieutil" commands in DellEMC Z9332f.
How I did it
Add 'pcie.yaml' in device/dell/[PLATFORM]/ directory.
How to verify it
Execute "pcieutil check" command.
Logs: UT_logs.txt
Why I did it
Update Makefile, so it does the following:
For a given platform, verify if platform/checkout/.ini exists and hence run the platform/checkout/template.j2. This allows platform code to be checked out during the 'make configure' stage.
How I did it
git clone git@github.com:Azure/sonic-buildimage.git
mkdir platform/cisco-8000
make init
make configure PLATFORM=cisco-8000
make all
This change is to add a gbsyncd container to accommodate the syncd process and the SAI libraries for the Credo gearbox chips.
How I did it
This container works similar to the existing Broadcom syncd container. Its main difference is that the SAI-related dynamic libraries are replaced by the ones for Credo gearbox chips, and the container only reacts to SAI events for the gearbox chips. The SAI libraries will be provided by the package libsai-credo_1.0_amd64.deb.
For the image build, the added container will be built and included in the Broadcom platform image, after $(LIBSAI_CREDO)_URL = is replaced to the correct value. For now, as $(LIBSAI_CREDO)_URL is empty, the container build is skipped in the image build.
After the container is included in the image, in the runtime, the container will begin with checking the existence of /usr/share/sonic/hwsku/gearbox_config.json; if that file is not provided, the container will exit by itself. Therefore, for platforms unrelated to the Credo chips, as long as they are not providing the file, they will not be affected by this change.
Why I did it
Added a check in determining CPU reset in fast-/warm-reboot in their respective platform plugin.
Introducing reboot plugin for "reboot" command to handle its own platform plugin.
How I did it
On branch s6100_fast_warm_check
Changes to be committed:
(use "git reset HEAD ..." to unstage)
modified: ../../debian/platform-modules-s6100.install
modified: ../scripts/fast-reboot_plugin
modified: ../scripts/platform_reboot_override
new file: ../scripts/reboot_plugin
modified: ../scripts/track_reboot_reason.sh
modified: chassis.py
How to verify it
Triggered cold-reset inside fast-reboot to test out the reboot-cause 2.0 API.
Why I did it
serial-getty service exited in Dell S6100 device randomly.
How I did it
Added serial-getty to monit services.
How to verify it
Stop serial-getty in ssh session and check whether the service restarts or not.
Included commits:
* dd01b56 disk_check updates:
* 8a74d03 [CLI][show][bgp] Fix the show ip bgp network command
* 679a4ba [MACsec]: Allow upgrade-docker for macsec container
* e9c73e8 [CLI][MPLS][Show] Added multi ASIC support for 'show mpls command'.
Signed-off-by: Neetha John <nejo@microsoft.com>
Why I did it
Changes in the buffer template did not trigger a new sonic-config-engine wheel build and the cached build was used for the PR merge. When the new wheel build got trigged, few sonic-cfggen testcases started failing because of the changes made in the buffer templates.
How to verify it
Updated the dependency to include buffer templates and built sonic_config_engine-1.0-py3-none-any.whl. Testcase failure was seen as expected
I have been seeing intermittent (~40%) build failures with the same error described in PR https://github.com/Azure/sonic-buildimage/pull/6592, even with that fix present
```
/usr/bin/ld: mibgroup/ip-forward-mib/ipCidrRouteTable/.libs/ipCidrRouteTable_interface.o: file not recognized: file truncated
...
libtool: error: 'mibgroup/ip-forward-mib/inetCidrRouteTable/inetCidrRouteTable_interface.lo' is not a valid libtool object
make[5]: *** [Makefile:1020: libnetsnmpmibs.la] Error 1
make[5]: *** Waiting for unfinished jobs....
```
#### How I did it
Use `-j1` for the libsnmp build regardless of the value of `$(MULTIARCH_QEMU_ENVIRON)`
#### How to verify it
Performed 10 builds of the libsnmp target (`target/debs/buster/libsnmp-base_5.7.3+dfsg-5_all.deb`) with and without this change. Without the change, hit the error 40% of the time. With the change did not see the error at all
Signed-off-by: Justin Sherman <jusherma@cisco.com>
