Submodule changes to be committed:
* src/sonic-platform-daemons 81318f7...e72f6cd (3):
> [ledd] Minor refactor; add unit tests (#143)
> [thermalctld] Report unit test coverage (#141)
> [psud] Increase unit test coverage (#140)
Fixes#6445
Because the ipmihelper.py script in the 9332 folder is slightly different than the common one (due to LGTM fixes), when the common one gets copied during build time it causes the workspace/build to become dirty.
Signed-off-by: Danny Allen <daall@microsoft.com>
Signed-off-by: Arvindsrinivasan Lakshmi Narasimhan arlakshm@microsoft.com
- Why I did it
This PR has the changes to support having different swss.rec and sairedis.rec for each asic.
The logrotate script is updated as well
- How I did it
Update the orchagent.sh script to use the logfile name options in these PRs(Azure/sonic-swss#1546 and Azure/sonic-sairedis#747)
In multi asic platforms the record files will be different for each asic, with the format swss.asic{x}.rec and sairedis.asic{x}.rec
Update the logrotate script for multiasic platform .
**- Why I did it**
Ledd is the last daemon that is not enabled to run in python3.
Even though there is a plan to deprecate this daemon and to replace it by something else it's one simple step toward python2 deprecation.
**- How I did it**
Changed the `command=` line for `ledd` in the `supervisord` configuration of `pmon`.
Copied what was done for other daemons.
**- How to verify it**
Booting a product that has a `led_control.py` should now show the ledd running in python3.
I ran `python3 -m pylint` on all `led_control.py` plugin which means that most of them should be python3 compliant.
There is however still a risk that some might not work.
Meet the requirement for the MUX_CABLE table that IPv6 loopbacks have a /128 prefix
Note that this change only affects the MUX_CABLE table, all other tables continue to use the loopback address provided in minigraph.
Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
- Why I did it
Initially, we used Monit to monitor critical processes in each container. If one of critical processes was not running
or crashed due to some reasons, then Monit will write an alerting message into syslog periodically. If we add a new process
in a container, the corresponding Monti configuration file will also need to update. It is a little hard for maintenance.
Currently we employed event listener of Supervisod to do this monitoring. Since processes in each container are managed by
Supervisord, we can only focus on the logic of monitoring.
- How I did it
We borrowed the event listener of Supervisord to monitor critical processes in containers. The event listener will take
following steps if it was notified one of critical processes exited unexpectedly:
The event listener will first check whether the auto-restart mechanism was enabled for this container or not. If auto-restart mechanism was enabled, event listener will kill the Supervisord process, which should cause the container to exit and subsequently get restarted.
If auto-restart mechanism was not enabled for this contianer, the event listener will enter a loop which will first sleep 1 minute and then check whether the process is running. If yes, the event listener exits. If no, an alerting message will be written into syslog.
- How to verify it
First, we need checked whether the auto-restart mechanism of a container was enabled or not by running the command show feature status. If enabled, one critical process should be selected and killed manually, then we need check whether the container will be restarted or not.
Second, we can disable the auto-restart mechanism if it was enabled at step 1 by running the commnad sudo config feature autorestart <container_name> disabled. Then one critical process should be selected and killed. After that, we will see the alerting message which will appear in the syslog every 1 minute.
- Which release branch to backport (provide reason below if selected)
201811
201911
[x ] 202006
Changes in this update:
37695c8 [show]: Use TCP Connection For Muxcable Commands (#1371)
8119ba2 Validations checks while creating and deleting a Portchannel (#1326)
3df267e [config] Fix Breakout mode option and BREAKOUT_CFG table check method (#1270)
9bd709b [show] Fix show arp in case with FDB entries, linked to default VLAN (#1357)
bc2d27e [generate_dump]: fix syntax error
signed-of-by: Tamer Ahmed <tamer.ahmed@microsoft.com>
Currently FRR is send Prefix with VNI information to FPMSYNCD. This PR allows FRR to send RMAC with EVPN Type5 prefix to fpmsyncd. This is a temp fix. This patch will be removed once neighorch is ready to handle the Prefix and ARP (containing RMAC) separately.
[ci]: download artifacts from master branch (#768)
Do not create fabric port if mapping is not available (#769)
[syncd] Comparison logic log also current attr value on set operation (#763)
Add fabric port test to vslib (#737)
[ci]: use sonicbld pool (#766)
[tests] Remove exit command blocking all tests to run (#765)
[vslib]: adapt macsec sai 1.7.1 (#755)
Add support for SAI_SWITCH_ATTR_AVAILABLE_IPMC_ENTRY needed by CRM (#756)
Signed-off-by: Danny Allen <daall@microsoft.com>
Fix#5026
There is a race condition between zebra server accepts connections and bgpd tries to connect. Bgpd has a chance to try to connect before zebra is ready. In this scenario, bgpd will try again after 10 seconds and operate as normal within these 10 seconds. As a consequence, whatever bgpd tries to sent to zebra will be missing in the 10 seconds. To avoid such a scenario, bgpd should start after zebra is ready to accept connections.
- Why I did it
platform.json and hwsku.json files are required for a feature called Dynamic Port Breakout
- How I did it
Created capability files according to platform specification SN4600C
- How to verify it
Full qualification requires bugs fixes reported under sonic-buildimage
NOTE: breakout to 4 is currently not available as of missing functionality in DPB implementation.
Signed-off-by: Vadym Hlushko <vadymh@nvidia.com>
- Why I did it
platform.json and hwsku.json files are required for a feature called Dynamic Port Breakout
- How I did it
Created capability files according to platform specification SN4410
- How to verify it
Full qualification requires bugs fixes reported under sonic-buildimage
Signed-off-by: Vadym Hlushko <vadymh@nvidia.com>
- Why I did it
platform.json and hwsku.json files are required for a feature called Dynamic Port Breakout
- How I did it
Created capability files according to platform specification SN3700
- How to verify it
Full qualification requires bugs fixes reported under sonic-buildimage
Signed-off-by: Vadym Hlushko <vadymh@nvidia.com>
- Why I did it
platform.json and hwsku.json files are required for a feature called Dynamic Port Breakout
- How I did it
Created capability files according to platform specification SN2410
- How to verify it
Full qualification requires bugs fixes reported under sonic-buildimage
NOTE: breakout to 4 is currently not available as of missing functionality in DPB implementation.
Signed-off-by: Vadym Hlushko <vadymh@nvidia.com>
- Why I did it
platform.json and hwsku.json files are required for a feature called Dynamic Port Breakout
- How I did it
Created capability files according to platform specification SN2100
- How to verify it
Full qualification requires bugs fixes reported under sonic-buildimage
Signed-off-by: Vadym Hlushko <vadymh@nvidia.com>
- Why I did it
platform.json and hwsku.json files are required for a feature called Dynamic Port Breakout
- How I did it
Created capability files according to platform specification SN2010
- How to verify it
Full qualification requires bugs fixes reported under sonic-buildimage
Signed-off-by: Vadym Hlushko <vadymh@nvidia.com>
- Why I did it
platform.json and hwsku.json files are required for a feature called Dynamic Port Breakout
- How I did it
Created capability files according to platform specification SN3800
- How to verify it
Full qualification requires bugs fixes reported under sonic-buildimage
Signed-off-by: Vadym Hlushko <vadymh@nvidia.com>
[DPB] added capability files for SN2700 platform
- Why I did it
platform.json and hwsku.json files are required for a feature called Dynamic Port Breakout
- How I did it
Created capability files according to platform specification SN2700
- How to verify it
Full qualification requires bugs fixes reported under sonic-buildimage
NOTE: breakout to 4 is currently not available as of missing functionality in DPB implementation.
Signed-off-by: Vadym Hlushko <vadymh@nvidia.com>
[DPB][MLNX][YANG] fixed range of max speed
- Why I did it
All Mellanox platforms require DPB modes with a specific set of speeds example
- How I did it
Extended regex pattern inside YANG model.
Supported platforms: SN2010, SN2100, SN2410, SN2700, SN3420, SN3700, SN3700C, SN3800, SN4600C, SN4410, SN4700
- How to verify it
Manually tested DPB CLI on all platform with all modes
Signed-off-by: Vadym Hlushko <vadymh@nvidia.com>
Avoid sonic-cfggen crashing when a server does not have a configured loopback address in the minigraph
Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
When building the sonic-slave-buster docker container, the node.js package is
installed to meet the requirements of the Azure DevOPs pipleline
build. Recently this install of node.js has been failing.
This commit fixes that build break by upgrading the
sonic-slave-buster build to install version 14.x of node.js which is the
current LTS version for buster.
**- Why I did it**
On the Mellanox platform, reboot cause is fetched from some certain sysfs which is created by the hw-management service. So determine-reboot-cause service shall start after hw-management, otherwise it could fail due to the related sysfs is not available yet.
**- How I did it**
Add a patch to the hw-management service to make sure determine-reboot-cause service should start after it.
Signed-off-by: Kebo Liu <kebol@nvidia.com>
**- Why I did it**
- The thermalctld daemon on the Pmon docker requires support from the thermal manager API.
**- How I did it**
- Removed the old function for detecting a faulty fan.
- Removed the old function for detecting excess temperature.
- Implement thermal_manager APIs based on ThermalManagerBase
- Implement thermal_conditions APIs based on ThermalPolicyConditionBase
- Implement thermal_actions APIs based on ThermalPolicyActionBase
- Implement thermal_info APIs based on ThermalPolicyInfoBase
- Add thermal_policy.json
It's been reported that accton fan monitor process keeps consuming memory after few days.
The amount of memory occupied increases in linear and never leased.
Signed-off-by: roy_lee <roy_lee@edge-core.com>
In order to build up device hierachy, PSU and module thermals are no longer child of chassis. PSU thermal belongs to PSU objects and SFP thermals belong to SFP object now. Need align this change in platform.json. Move thermal objects to correct parent device
* [warm boot finalizer] only wait for enabled components to reconcile
Define the component with its associated service. Only wait for components that have associated service enabled to reconcile during warm reboot.
Signed-off-by: Ying Xie <ying.xie@microsoft.com>
- Why I did it
Management framework (CVL) needs to call lyd_check_mandatory_tree() for validation and hence exported lyd_check_mandatory_tree() as an API.
- How I did it
Added "API" keyword before lyd_check_mandatory_tree() definition.
- How to verify it
There is no functionality code change here and no specific steps to verify it. Management framework (CVL) should be able to call this function and no patching and compilation error should be seen.
- Description for the changelog
Added "API" keyword before export lyd_check_mandatory_tree() function definition.
**- Why I did it**
Earlier today we found a bug in the SONiC TSA implementation.
TSC shows incorrect output (see below) in case we have a route-map which contains TSA route-map as a prefix.
```
admin@str-s6100-acs-1:~$ TSC
Traffic Shift Check:
System Mode: Not consistent
```
The reason is that TSC implementation has too loose regexps in TSA utilities, which match wrong route-map entries:
For example, current TSC matches following
```
route-map TO_BGP_PEER_V4 permit 200
route-map TO_BGP_PEER_V6 permit 200
```
But it should match only
```
route-map TO_BGP_PEER_V4 permit 20
route-map TO_BGP_PEER_V4 deny 30
route-map TO_BGP_PEER_V6 permit 20
route-map TO_BGP_PEER_V6 deny 30
```
**- How I did it**
I fixed it by using egrep with `^` and `$` regexp markers which match begin and end of the line.
**- How to verify it**
1. Add follwing entry to FRR config:
```
str-s6100-acs-1#
str-s6100-acs-1# conf t
str-s6100-acs-1(config)# route-map TO_BGP_PEER_V4 permit 200
str-s6100-acs-1(config-route-map)# end
```
2. Use the TSC command and check output. It should show normal.
```
admin@str-s6100-acs-1:~$ TSC
Traffic Shift Check:
System Mode: Normal```
**- Why I did it**
To enable running Pytest unit tests before building the Python 3 sonic-platform-common package
**- How I did it**
- Add Python 3 sonic-config-engine package as a dependency of Python 3 sonic-platform-common package (needed for both runtime and unit tests)
- No longer disable unit tests when building Python 3 sonic-platform-common package
**- Why I did it**
Prior to SONiC using Debian Buster, we needed to build Python 3.5 or newer from source for installation in the SNMP container, becuase it wasn't available from the Debian repository for Jessie or Stretch. Now that all containers are based on Buster, we simply install Python 3.7 from the Debian repository in the host as well as all containers. We are no longer building Python 3 from source, so the Makefile is unused and we no longer need to install build dependencies in the slave containers.
**- How I did it**
- Remove Python 3 makefile
- No longer install Python 3 build dependencies in the slave containers.
The only Python code in the SwSS package, restore_neighbors.py, was recently converted to Python 3 and most dependencies were updated as part of #6207. However, the SwSS makefile still listed the Python 2 version of the swsscommon package as a dependency. This caused Python 2-related packages to be installed in containers unnecessarily.
