Update the test command for test_ssdhealth in show_test.py #32
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
What I did Add docs for dhcp_realy show/clear cli How I did it Add docs for dhcp_realy show/clear cli Signed-off-by: Yaqiang Zhu <[email protected]>
- What I did Add support of secure warm-boot to SONiC. Basically, warm-boot is supporting to load a new kernel without doing full/cold boot. That is by loading a new kernel and exec with kexec Linux command. As a result of that, even when the Secure Boot feature is enabled, still a user or a malicious user can load an unsigned kernel, so to avoid that we added the support of the secure warm boot. More Description about this feature can be found in the Secure Boot HLD: sonic-net/SONiC#1028 - How I did it In general, Linux support it, so I enabled this support by doing the follow steps: I added some special flags in Linux Kernel when user build the sonic-buildimage with secure boot feature enabled. I added a flag "-s" to the kexec command Note: more details in the HLD above. - How to verify it * Good flow: manually just install with sonic-installed a new secure image (a SONiC image that was build with Secure Boot flag enabled) after the secure image is installed, do: warm-reboot Check now that the new kernel is really loaded and switched. * Bad flow: Do the same steps 1-2 as a good flow but with an insecure image (SONiC image that was built without setting Secure Boot enabled) After the insecure image is installed, and triggered warm-boot you should get an error that the new unsigned kernel from the unsecured image was not loaded. Automation test - TBD
… vlan (#2678) What I did Remove add field of vlanid to DHCP_RELAY table while add vlan which would cause conflict with yang model. How I did it Remove add field of vlanid to DHCP_RELAY table while add vlan How to verify it By unit tests Signed-off-by: Yaqiang Zhu <[email protected]>
Signed-off-by: maipbui <[email protected]> #### What I did `pickle` can lead to lead to code execution vulnerabilities. Recommend to serializing the relevant data as JSON. #### How I did it Replace `pickle` by `json` #### How to verify it Pass UT Manual test
…o support for muxcable (#2414)
This PR adds the support for adding some utility commands for muxacble
This includes commands for health, operationtime, queueinfo, resetcause
vdahiya@sonic:~$ show mux health Ethernet4
PORT ATTR HEALTH
--------- --------------- --------
Ethernet4 health_check Ok
vdahiya@sonic:~$ show mux health Ethernet4 --json
{
"health_check": "Ok"
}
vdahiya@sonic:~$ show mux operation Ethernet4 --json
{
"operation_time": "22:22"
}
vdahiya@sonic:~$ show mux operation Ethernet4
PORT ATTR OPERATION_TIME
--------- -------------- ----------------
Ethernet4 operation_time 22:22
vdahiya@sonic:~$
vdahiya@sonic:~$ show mux resetcause Ethernet4
PORT ATTR RESETCAUSE
--------- ----------- ------------
Ethernet4 reset_cause 0
vdahiya@sonic:~$ show mux resetcause Ethernet4 --json
{
"reset_cause": "0"
}
vdahiya@sonic:~$ show mux queueinfo Ethernet4 --json
{
"Remote": "{'VSC': {'r_ptr': 0, 'w_ptr': 0, 'total_count': 0, 'free_count': 0, 'buff_addr': 0, 'node_size': 0}, 'UART1': {'r_ptr': 0, 'w_ptr': 0, 'total_count': 0, 'free_count': 0, 'buff_addr': 209870, 'node_size': 1682183}, 'UART2': {'r_ptr': 13262, 'w_ptr': 3, 'total_count': 0, 'free_count': 0, 'buff_addr': 12, 'node_size': 0}}",
"Local": "{'VSC': {'r_ptr': 0, 'w_ptr': 0, 'total_count': 0, 'free_count': 0, 'buff_addr': 0, 'node_size': 0}, 'UART1': {'r_ptr': 0, 'w_ptr': 0, 'total_count': 0, 'free_count': 0, 'buff_addr': 209870, 'node_size': 1682183}, 'UART2': {'r_ptr': 13262, 'w_ptr': 3, 'total_count': 0, 'free_count': 0, 'buff_addr': 12, 'node_size': 0}}"
}
This reverts commit 6fe8599.
…oot (#2694) - What I did Add more logs for config reload/config minigraph/warm-reboot/fast/reboot to identify in the log (notice level) what was the command executed which could cause a service affect. - How I did it Add more logs for config reload/config minigraph/warm-reboot/fast/reboot. - How to verify it Manual test
* add rdma gcu unit test * fix comment * clean unused code * clean format * extend to mock patchapplier, in place of changeapplier * replace tabs with spaces
Why I did In device that doesn't have dhcp_relay service, restart dhcp_relay after add/del vlan would encounter failed How I did it Add support to check whether device is support dhcp_relay service. How to verify it 1. Unit test 2. Build and install in device Signed-off-by: Yaqiang Zhu <[email protected]>
What I did These 3 packages maybe purged by default. Do not block pipeline. Download deb/whl packages only to accelerate download process. How I did it How to verify it
… DB (#2691) Fixes: 201911 to 202205 warm upgrade failure in fpmsyncd reconciliation due to missing weight attr in routes. (sonic-net/sonic-buildimage#12625) How I did it Check for missing attribute weight in APPLDB route entries. If found missing this attribute is added with empty value. How to verify it Verified on physical device. 201911 to 202205 upgrade worked fine.
…utdown (#2714) Goal: Preserve logs during TOR upgrades and shutdown Need: Below PRs moved logs from disk to tmpfs for specific hwskus. Due to these changes, shutdown path logs are now lost. The logs in shutdown path are crucial for debug purposes. sonic-net/sonic-buildimage#13805 sonic-net/sonic-buildimage#13587 sonic-net/sonic-buildimage#13587 How I did it Check if logs are on tmpfs. If yes, backup logs from /var/log How to verify it Verified on a physical device - logs on tmfs are backed up for past 30 minutes.
…#2531) * [route_check] implement a check for FRR routes not marked offloaded * Implemented a route_check functioality that will check "show ip route json" output from FRR and will ensure that all routes are marked as offloaded. If some routes are not offloaded for 15 sec, this is considered as an issue and a mitigation logic is invoked.
What I did Warm-reboot fails on kvm due to non-zero exit upon command bootctl status 2>/dev/null | grep -c "Secure Boot: enabled" How I did it Added || true to return 0 when previous command fails. Added CHECK_SECURE_UPGRADE_ENABLED to check output of previous command Added debug logs How to verify it Run warm-reboot on kvm and physical device when increased verbosity. Expects debug log to indicate secure/non secure boot. Successful warm reboot
What I did probe mux direction not always return success. Sample output of: while [ 1 ]; do date; show mux hwmode muxdirection; show mux status; sleep 1; done Mon 27 Feb 2023 03:12:25 PM UTC Port Direction Presence ----------- ----------- ---------- Ethernet16 unknown True PORT STATUS HEALTH HWSTATUS LAST_SWITCHOVER_TIME ----------- -------- -------- ------------ --------------------------- Ethernet16 standby healthy inconsistent 2023-Feb-25 07:55:18.269177 If we increase the timeout to 0.5 secs to get the values back from ycabled, this will remove the inconsistency issue, and display the consistent values, because while telemetry is going on, the time to get actual mux value takes significantly longer than 0.1 seconds. PORT STATUS HEALTH HWSTATUS LAST_SWITCHOVER_TIME ----------- -------- -------- ------------ --------------------------- Ethernet16 standby healthy consistent 2023-Feb-25 07:55:18.269177 How I did it How to verify it Manually run changes on setup worst-case CLI return time could be 16 seconds for 32 ports. on avg each port is 200 mSec if telemetry is going, but on average show command will return in < 1 sec for all 32 ports. Signed-off-by: vaibhav-dahiya <[email protected]>
* Add status for ACL_TABLE and ACL_RULE in STATE_DB
#### What I did SONiC related packages shouldn't be intalled from Pypi. It is security compliance requirement. Check SONiC related packages when using setup.py.
What I did Fix the bug of GCU vlan interface modification. It should call ip neigh flush dev after removing interface ip. The fix is basically following config CLI's tradition. How I did it Add vlanintf service validator to check if extra step of ip neigh flush is needed. How to verify it GCU E2E test in dualtor testbed.
*In case user has configured an IPv6 address on an interface in CONFIG DB in non simplified form like 2000:31:0:0::1/64 it is present in a simplified form in ASIC_DB. This leads to route_check failure since it just compares strings.
This should come along with sonic-buildimage PR (sonic-net/sonic-buildimage#13484) implementing fast-reboot finalizing logic in finalize-warmboot script and other submodules PRs utilizing the change. This PR should come along with the following PRs as well: sonic-net/sonic-swss-common#742 sonic-net/sonic-platform-daemons#335 sonic-net/sonic-sairedis#1196 This set of PRs solves the issue sonic-net/sonic-buildimage#13251 What I did Remove the timer used to clear fast-reboot entry from state-db, instead it will be cleared by fast-reboot finalize function implemented inside finalize-warmboot script (which will be invoked since fast-reboot is using warm-reboot infrastructure). As well instead of having "1" as the value for fast-reboot entry in state-db and deleting it when done it is now modified to set enable/disable according to the context. As well all scripts reading this entry should be modified to the new value options. How I did it Removed the timer usage in the fast-reboot script and adding fast-reboot finalize logic to warm-reboot in the linked PR. Use "enable/disable" instead of "1" as the entry value. How to verify it Run fast-reboot and check that the state-db entry for fast-reboot is being deleted after finalizing fast-reboot and not by an expiring timer.
…ar_qos (#2720) - What I did This is an enhancement of PR #2503 - How I did it On top of waiting for BUFFER_POOL_TABLE to be cleared from APPL_DB, we need to wait for KEY_SET and DEL_SET as well. KEY_SET and DEL_SET are designed to accommodate the APPL_DB entries that were updated by manager daemons but have not yet been handled by the orchagent. In this case, even if the buffer tables are empty, entries in KEY_SET or DEL_SET will be in the buffer tables later on. So, we need to wait for key set tables as well. Do not delay for traditional buffer manager because it does not remove any buffer table. Provide a CLI option to print the detailed message if there is any table item which still exists - How to verify it Manually test and unit test - Previous command output (if the output of a command-line utility has changed) Running command: /usr/local/bin/sonic-cfggen -d --write-to-db -t /usr/share/sonic/device/x86_64-mlnx_msn2410-r0/ACS-MSN2410/buffers_dynamic.json.j2,config-db -t /usr/share/sonic/device/x86_64-mlnx_msn2410-r0/ACS-MSN2410/qos.json.j2,config-db -y /etc/sonic/sonic_version.yml - New command output (if the output of a command-line utility has changed) Only with option --verbose there are new output. Without the option, the output is the same as it is. admin@mtbc-sonic-01-2410:~$ sudo config qos reload --verbose Some entries matching BUFFER_*_TABLE:* still exist: BUFFER_QUEUE_TABLE:Ethernet108:0-2 Some entries matching BUFFER_*_SET still exist: BUFFER_PG_TABLE_KEY_SET Some entries matching BUFFER_*_TABLE:* still exist: BUFFER_QUEUE_TABLE:Ethernet108:0-2 Some entries matching BUFFER_*_SET still exist: BUFFER_PG_TABLE_KEY_SET Some entries matching BUFFER_*_TABLE:* still exist: BUFFER_QUEUE_TABLE:Ethernet108:0-2 Running command: /usr/local/bin/sonic-cfggen -d --write-to-db -t /usr/share/sonic/device/x86_64-mlnx_msn2410-r0/ACS-MSN2410/buffers_dynamic.json.j2,config-db -t /usr/share/sonic/device/x86_64-mlnx_msn2410-r0/ACS-MSN2410/qos.json.j2,config-db -y /etc/sonic/sonic_version.yml
Fix DB migrator logic for migrating fast-reboot table, fixing #2621 db_migrator. How I did it Checking if fast-reboot table exists in DB. How to verify it Verified manually, migrating after fast-reboot and after cold/warm reboot.
What I did show vlan brief will only be showing dhcpv4 addresses and not dhcpv6 destination Signed-off-by: Vivek Reddy Karri <[email protected]>
This reverts commit 1518ca9.
The test fails with python3.7 (works in 3.9) when stopping patch which hasn't been started. We can always mock check_output call and if FRR_ROUTES is not defined return empty dictionary by the mock. #### What I did Removed check_frr_patch mock to fix UT running on python3.7 #### How I did it Removed the mock #### How to verify it Run unit test in stretch env
…o external interfaces (#2703) Fix the `show interface counters` throwing exception issue where device do not have any external ports and all are internal links (ethernet or fabric) which is possible in chassis
This reverts commit 54e2635. Due to sonic-net/sonic-buildimage#14089 Signed-off-by: Mai Bui <[email protected]>
Signed-off-by: irene_pan [email protected]
When enabling mgmtvrf, NTP vrf needs to be configured as "mgmt"
Revert "When enabling mgmtvrf, NTP vrf needs to be configured as "mgmt""
Signed-off-by: irene_pan [email protected]
When mgmtvrf is enabled, the NTP vrf should be changed to "mgmt"
[VRF] Wait to delete VRF completely before adding the same VRF.
- Fix the unexpected exception error that appears when running "show ip route vrf all" when key 'interfaceName' does not exist. - Revise some output formats to ensure brackets are properly paired.
…w_vrf_command [show][vrf] Improve the speed of show command for vrf
…on_error_for_show_ip_route_vrf_all [show] Fix exception error for "show ip route vrf all"
…le (#3177) * Retrieve firmware version fields from TRANSCEIVER_FIRMWARE_INFO table Signed-off-by: Mihir Patel <[email protected]> * Fixed test failures * Removed update_firmware_info_to_state_db function * Revert "Removed update_firmware_info_to_state_db function" This reverts commit 68f52a2c3352bc709ab2e3ffe793761f7176a4f0. --------- Signed-off-by: Mihir Patel <[email protected]>
[Sync PR]: Sync #3177 to fix AS9817-64O pytest failed
…wVrf Fix the unit test error for TestShowVrf
It will fail when there is no VLAN interface for the VLAN
…ocal-only-fail-on-vlan-intf Fix enable ipv6-link-local-only fail on VLAN interface without IP
roger530-ho
changed the title
|
Submit this to incorrect branch |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What I did
Due to the build failure message as follows :
How I did it
Update the test command
How to verify it
Previous command output (if the output of a command-line utility has changed)
New command output (if the output of a command-line utility has changed)