previously, get_num_asics() returns the maximum number of asics. however, the asic_count
should be actual number of asics populated which can be get from get_asic_presence_list().
ADO: 25158825
Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
Why I did it
Few commands in multiasic platforms when run with the "sudo ip netns exec asic0 " option was taking like 15 mins to get the o/p. This behavior of sudo getting hung was seen by just doing this
jujoseph@svcstr-server-2:~ sudo ip netns exec asic0 bash
jujoseph@svcstr-server-2:~ sudo ls
deally sudo is not needed as we have /bin/ip netns identify present in /etc/sudoers file. Hence removing it
Why I did it
get_system_mac was returning 'None' mac for system without eeprom.
get_system_mac for marvell platform checks for mac in eeprom, profile.ini(hwsku file) and eth0. Check for valid mac returned by syseeprom was incorrect. Which was resulting in bypassing mac get from profile.ini and eth0.
How I did it
get_system_mac already has a logic to get first valid mac.
Removed null check for mac returned by eeprom.
Corrected the check for profile.ini file by checking if file exist.
How to verify it
Executed sonic-cfggen to check valid mac address is getting configured in config_db.json with/without profile.ini.
Signed-off-by: Pavan Naregundi <pnaregundi@marvell.com>
Added support data for fabric monitoring in CONFIG_DB
The CONFIG_DB now has the FABRIC_MONITOR|FABRIC_MONITOR_DATA table for default value for fabric port monitoring. An example output of getting this table is:
sonic-db-cli CONFIG_DB hgetall "FABRIC_MONITOR|FABRIC_MONITOR_DATA"
{'monErrThreshCrcCells': '1', 'monErrThreshRxCells': '61035156', 'monPollThreshIsolation': '1', 'monPollThreshRecovery': '8'}
The CONFIG_DB now also has a table for each fabric port for its isolate status.
An example output of getting this table is:
sonic-db-cli CONFIG_DB hgetall "FABRIC_PORT|Fabric20"
{'alias': 'Fabric20', 'isolateStatus': 'False', 'lanes': '20'}
Co-authored-by: jfeng-arista <98421150+jfeng-arista@users.noreply.github.com>
- Run pre-commit tox profile to trim all trailing blanks
- Use several commits with a per-folder based strategy
to ease their merge
Issue #15114
Signed-off-by: Guillaume Lambert <guillaume.lambert@orange.com>
Add new Nokia build target and establish an arm64 build:
Platform: arm64-nokia_ixs7215_52xb-r0
HwSKU: Nokia-7215-A1
ASIC: marvell
Port Config: 48x1G + 4x10G
How I did it
- Change make files for saiserver and syncd to use Bulleseye kernel
- Change Marvell SAI version to 1.11.0-1
- Add Prestera make files to build kernel, Flattened Device Tree blob and ramdisk for arm64 platforms
- Provide device and platform related files for new platform support (arm64-nokia_ixs7215_52xb-r0).
Why I did it
replace yaml.load to yaml.safe_load because yaml.safe_load is more secure
Work item tracking
Microsoft ADO (number only): 15022050
How I did it
How to verify it
Verified in DUT 201911 which yaml version < 5.1
* Fix backend port channels and routes being displayed
In `show interface portchannel` and `show ip route`, backend port
channels and routes were being displayed. This is due to changes in #13660.
Fix these issues by switching to reading from PORTCHANNEL_MEMBERS table
instead.
Fixes#14459.
* Replace table name with constant
Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
- Why I did it
To solve an issue with upgrade with fast-reboot including FW upgrade which has been introduced since moving to fast-reboot over warm-reboot infrastructure.
As well, this introduces fast-reboot finalizing logic to determine fast-reboot is done.
- How I did it
Added logic to finalize-warmboot script to handle fast-reboot as well, this makes sense as using fast-reboot over warm-reboot this script will be invoked. The script will clear fast-reboot entry from state-db instead of previous implementation that relied on timer. The timer could expire in some scenarios between fast-reboot finished causing fallback to cold-reboot and possible crashes.
As well this PR updates all services/scripts reading fast-reboot state-db entry to look for the updated value representing fast-reboot is active.
- How to verify it
Run fast-reboot and check that fast-reboot entry exists in state-db right after startup and being cleared as warm-reboot is finalized and not due to a timer.
Update sonic-py-common, add missing dependency to redis-dump-load.
#### Why I did it
The script sonic_db_dump_load.py in sonic-py-common is depends on redis-dump-load, however the dependency is missing.
#### How I did it
Add redis-dump-load dependency.
#### How to verify it
Pass all E2E test case.
#### Description for the changelog
Update sonic-py-common, add missing dependency to redis-dump-load.
Why I did it
When getting system mac of centec platform, it would increase by 1 the last byte of mac, but it could not consider the case of carry.
How I did it
Firstly, I would replace the ":" with "" of mac to a string.
And then, I would convert the mac from string to int and increase by 1, at last convert it to string with inserting ":".
Signed-off-by: Arvindsrinivasan Lakshmi Narasimhan arlakshm@microsoft.com
Why I did it
Fixes#12575 and #12575
How I did it
In the PR sonic-net/sonic-platform-daemons#311 chassisd updates to CHASSIS_FABRIC_ASIC_INFO with the fabric asic info.
Updating the asic_status.py to read from the correct table.
How to verify it
test on chassis
Signed-off-by: Arvindsrinivasan Lakshmi Narasimhan <arlakshm@microsoft.com>
This PR is part of the following HLD:
Persistent loglevel HLD: sonic-net/SONiC#1041
- Why I did it
After the Logger tables moved from the LOGLEVEL_DB to the CONFIG_DB and the jinja2_cache was deleted the LOGLEVEL_DB is not in use.
- How I did it
Removed the LOGLEVEL_DB from the SONiC code
- How to verify it
All tests were passed
Signed-off-by: maipbui <maibui@microsoft.com>
#### Why I did it
`subprocess` is used with `shell=True`, which is very dangerous for shell injection.
#### How I did it
remove `shell=True`, use `shell=False`
#### How to verify it
Manual test
Pass UT
Porting sonic_db_dump_load.py from sonic-py-swsssdk to sonic-py-common.
#### Why I did it
sonic-py-swsssdk will be deprecate, so porting sonic_db_dump_load.py to sonic-py-common.
#### How I did it
Copy sonic_db_dump_load.py to sonic-py-common, and fix minor API different.
#### How to verify it
Pass all E2E test.
The platform_tests/test_advanced_reboot.py::test_warm_reboot will cover this script.
#### Which release branch to backport (provide reason below if selected)
<!--
- Note we only backport fixes to a release branch, *not* features!
- Please also provide a reason for the backporting below.
- e.g.
- [x] 202006
-->
- [ ] 201811
- [ ] 201911
- [ ] 202006
- [ ] 202012
- [ ] 202106
- [ ] 202111
- [ ] 202205
#### Description for the changelog
Porting sonic_db_dump_load.py from sonic-py-swsssdk to sonic-py-common.
#### Ensure to add label/tag for the feature raised. example - [PR#2174](https://github.com/sonic-net/sonic-utilities/pull/2174) where, Generic Config and Update feature has been labelled as GCU.
#### Link to config_db schema for YANG module changes
<!--
Provide a link to config_db schema for the table for which YANG model
is defined
Link should point to correct section on https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-yang-models/doc/Configuration.md
-->
#### A picture of a cute animal (not mandatory but encouraged)
Signed-off-by: maipbui <maibui@microsoft.com>
#### Why I did it
`getstatusoutput()` function from `subprocess` module has shell injection issue because it includes `shell=True` in the implementation
Eliminate duplicate code
#### How I did it
Reimplement `getstatusoutput_noshell()` and `getstatusoutput_noshell_pipe()` functions with `shell=False`
Add `check_output_pipe()` function
#### How to verify it
Pass UT
Why I did it:
API get_device_runtime_metadata() added by #11795 uses merge operator for dict but that is supported only for python version >=3.9. This API will be be used by scrips eg:hostcfgd which is still build for buster which does not have python 3.9 support.
Why I did it
VoQ chassis supervisor will have Fabric asics and the sub_role for fabric asics will be "Fabric".
The fabric asics namespaces are not being returned in get_all_namespaces() and is required in caclmgrd to add right cacl to allow internal docker traffic from fabric asic namespaces.
test_cacl_application fails on VoQ chassis Supervisor with the error:
Failed: Missing expected iptables rules: set(['-A INPUT -s 240.127.1.1/32 -d 240.127.1.1/32 -j ACCEPT', '-A INPUT -s 240.127.1.3/32 -d 240.127.1.1/32 -j ACCEPT', '-A INPUT -s 240.127.1.2/32 -d 240.127.1.1/32 -j ACCEPT'])
How I did it
Update get_all_namespaces to return fabric namespaces list.
How to verify it
Verified on VoQ chassis.
- Why I did it
Profiled the execution for the following cmd intfutil -c status
- How I did it
Cached the following information:
1. get_sonic_version_info()
2. get_platform_info()
None of the API exposed to the user libraries (for eg: sonic-utilities) has been modified
These methods involve reading text files or from redis. Thus, caching helped to improve the execution time
- How to verify it
Added UT's.
Verified on the device
Signed-off-by: Vivek Reddy Karri <vkarri@nvidia.com>
Why I did it
Currently the CLI commands show interface status show interface counters and show interface description displays Ethernet-IB and Ethernet-Rec ports in the output. These are internal ports should only be displayed when the option -d all is used for the above mentioned CLI commands
How I did it
Add the port roles Inb and Rec when classifing a port as internal port.
How to verify it
Verify the CLI output of the command show interface status doesnt display the Ethenet-IB and Ethernet-Rec port when -d all option in not present
Before
Signed-off-by: Arvindsrinivasan Lakshmi Narasimhan <arlakshm@microsoft.com>
Why I did it
On a supervisor card in a chassis, syncd/teamd/swss/lldp etc dockers are created for each Switch Fabric card. However, not all chassis would have all the switch fabric cards present. In this case, only dockers for Switch Fabrics present would be created.
The monit 'container_checker' fails in this scenario as it is expecting dockers for all Switch Fabrics (based on NUM_ASIC defined in asic.conf file).
#### Why I did it
To deprecate sonic-py-swsssdk, need move some code to sonic-py-common.
#### How I did it
Porting util.py and port_util.py from sonic-py-swsssdk to sonic-py-common.
#### How to verify it
Pass UT.
Pass all E2E test.
#### Which release branch to backport (provide reason below if selected)
<!--
- Note we only backport fixes to a release branch, *not* features!
- Please also provide a reason for the backporting below.
- e.g.
- [x] 202006
-->
- [ ] 201811
- [ ] 201911
- [ ] 202006
- [ ] 202012
- [ ] 202106
- [ ] 202111
- [ ] 202205
#### Description for the changelog
Porting util.py and port_util.py from sonic-py-swsssdk to sonic-py-common.
Co-authored-by: liuh-80 <azureuser@liuh-dev-vm-02.5fg3zjdzj2xezlx1yazx5oxkzd.hx.internal.cloudapp.net>
#### Why I did it
Switch py-common from swsssdk to swsscommon.
#### How I did it
Change code and make file to use swsscommon.
#### How to verify it
Pass all UT and E2E test.
#### Which release branch to backport (provide reason below if selected)
<!--
- Note we only backport fixes to a release branch, *not* features!
- Please also provide a reason for the backporting below.
- e.g.
- [x] 202006
-->
- [ ] 201811
- [ ] 201911
- [ ] 202006
- [ ] 202012
- [ ] 202106
- [ ] 202111
#### Description for the changelog
<!--
Write a short (one line) summary that describes the changes in this
pull request for inclusion in the changelog:
-->
#### Link to config_db schema for YANG module changes
<!--
Provide a link to config_db schema for the table for which YANG model
is defined
Link should point to correct section on https://github.com/Azure/SONiC/wiki/Configuration.
-->
#### A picture of a cute animal (not mandatory but encouraged)
#### Why I did it
This function is critical for is_multi_asic() and SonicDBConfig initializing. No explicit reading ConfigDB. Otherwise it will implicitly trigger SonicDBConfig initializing.
#### How I did it
1. No explicit reading ConfigDB in get_asic_conf_file_path()
2. Collect asic_conf_path_candidates lazily to prevent any unnecessary side effect and improve the performance
On a multi-asic Supervisor card, running commands like
'show interface counter' opens a confid_db connection per
namespace per interface which results in many duplicate connections
exceeding the allowed open file handles. This causes the command to fail.
Caching the connections to prevent duplicate handles.
This interface type is used for recirculation on chassis.
The definition is required to prevent this interface from being
considered a physical interface in sonic-platform-common and
sonic-platform-daemon
* Routed subinterfae enhancements HLD #833
* Adding python API support to get routed subinterface long name to get correct parent interface for the routed subinterface.
Added get_system_mac support for cisco-8000 device
Why I did it
This is required to assign unique MACs to namespaces on Backend and Frontend asics
for cisco-8000 platforms
How I did it
Add vendor specific hook in get_system_mac. The MAC address are read from /profile.ini
file
How to verify it
config load_minigraph on a multi-asic system
config save
check mac addresses in DEVICE_METADATA section in each config_db json file
* [multi-asic][cli][chassis-db] Avoiding connecting to chassis db
Currently, for all the cli commands, we connect to all databases
mentioned in the database_config.json. The database_config.json also
includes the databases from chassis redis server from supervisor card.
It is unneccessary to connect to databases from chassis redis server
when cli commands are executed form linecard. But we need to allow
connection to chassis databases when the cli commands are executed from
supervisor card.
The changes in this PR fixes this problem. This PR requires that
asic.conf in supervisor card includes VOQ_SUPERVISOR with value 1 to
indentify the supervisor card. The connect_to_all_dbs_for_ns() is
changed to skip chassis databases form the list of collected databases
if the card is not supervisor card.
#### 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
To ensure any environment variables which are configured in the build/test environment do not influence the behavior of sonic-py-common during unit tests. For example, variables which might be set by continuous integration pipelines.
#### How I did it
Add class-scoped pytest fixture to `TestDeviceInfo` class which stashes the current environment variables, clears them and yields. Once all the test cases in the class finish, the fixture will restore the original environment variables.
Also remove unnecessary unittest-style setup and teardown functions from interface_test.py
#### Why I did it
These methods were added to make some convenient platform and chassis information methods accessible through sonic-py-common. These methods were refactored from sonic-utilities and are used in the `show platform summary` and `show version` commands.
#### How I did it
There are two methods, one is `get_platform_info()` which simply calls local methods to collect useful platform information into a dictionary format, this came directly from sonic-utilities.
#### Why I did it
Allowing an application to set a stop timeout for processes and threads provides the following benefits:
1. Prevents the application from hanging indefinitely in the case a process or thread does not exit
2. Allow ProcessTaskBase a chance to let the process exit gracefully before attempting to kill it
Default values are as follows:
- ProcessTaskBase: 1 second
- ThreadTaskBase: No timeout
#### How I did it
- Add optional `stop_timeout_secs` parameter to initializers of ProcessTaskBase and ThreadTaskBase
- Additionally:
- Prefix private attributes with an underscore
- Remove obsolete comments
#### Why I did it
To eliminate the need to write duplicate code in order to import a Python module from a source file.
#### How I did it
Add `general` module to sonic-py-common, which contains a `load_module_from_source()` function which supports both Python 2 and 3.
Call this new function in:
- sonic-ctrmgrd/tests/container_test.py
- sonic-ctrmgrd/tests/ctrmgr_tools_test.py
- sonic-host-services/tests/determine-reboot-cause_test.py
- sonic-host-services/tests/hostcfgd/hostcfgd_test.py
- sonic-host-services/tests/procdockerstatsd_test.py
- sonic-py-common/sonic_py_common/daemon_base.py
Fix a strange bug introduced by https://github.com/Azure/sonic-buildimage/pull/6832 which would only occur in environments with both Python 2 and Python 3 installed (e.g., the PMon container). Error messages such as the following would be seen:
```
ERR pmon#ledd[29]: Failed to load ledutil: module 'importlib' has no attribute 'machinery'
```
This is very odd, and it seems like the Python 2 version of importlib, which is basically just a stub, is taking precedence over the Python 3 version. I found that this occurs when calling `import importlib`. However, calling `import importlib.machinery` and `import importlib.util` causes the proper package to be referenced, and the `machinery` and `util` modules are loaded successfully. This is how it is specified in examples in the official documentation, however there is nothing mentioned regarding that it *should* be done this way or that `import importlib` is unreliable.
Also, since sonic-py-common is still used in environments with Python 2 installed we should maintain support for both Python 2 and 3 until we completely deprecate Python 2, so I have added this back in.
Migrate from using the `imp` module to using the `importlib` module. As of Python 3, the `imp` module has been deprecated in favor of the `importlib` module.
