As part of migrating all Python-based package installers to wheel format rather than Debian packages. Also to allow for easily building a Python 3 version of the package in the near future.
- Also remove some references to sonic-daemon-base which I previously missed and add missing sonic-py-common dependency for sonic-pcied.
Original converting from register is wrong, it makes the fan speed much higher than it is. Change the way fan speed is calculated from CPLD.
Signed-off-by: roy_lee <roy_lee@accton.com>
Calculate pool size in t1 as 24 * downlink port + 8 * uplink port
- Take both port and peer MTU into account when calculating headroom
- Worst case factor is decreased to 50%
- Mellanox-SN2700-C28D8 t0, assume 48 * 50G/5m + 8 * 100G/40m ports
- Mellanox-SN2700 (C32)
- t0: 16 * 100G/5m + 16 * 100G/40m
- t1: 16 * 100G/40m + 16 * 100G/300m
Signed-off-by: Stephen Sun <stephens@mellanox.com>
Co-authored-by: Stephen Sun <stephens@mellanox.com>
HW set qsfp port to reset at default. so need SW to set to normal when boot.
1. Modify cpld driver to invert reset offset value
2. Set to normal when boot.
Calls to cfggen take considerable time. With batch mode, we will have the ability
to reduce number of calls from services.
Example of the batch mode command:
sonic-cfggen -t template-1.j2 -t template-2.j2,config-db -t template-3.j2,config-db -t template-4.j2,file1 -t template-5.j2,file2 --write-to-db.
template-1.j2 will be rendered to stdout since it is missing the dest part. stdout is default
config-db is a special keyword that will inject the rendered template into internal data structure. The internal data structure gets written to redis-db with --write-to-db switch. In the case the user would like to write to a file named config-db, it could be given as /config-db or ./config-db
signed-off-by: Tamer Ahmed <tamer.ahmed@microsoft.com>
python3-swsscommon is newly added build target besides originally python2 version of swsscommon library. Add this target to buildimage rules so we could make target/debs/buster/python3-swsscommon_1.0.0_amd64.deb
NUM_ASIC environment variable was added so that it could be used by other utilities.
This is not being used by any other utility or docker, hence removing the addition of NUM_ASIC environment variable.
Also, the environment variable was added by adding the variable value to /etc/environ file.
Upon each reboot, this file gets updated with the NUM_ASIC value but the existing value was not removed.
This causes multiple lines getting appended in /etc/environ file upon each reboot.
Signed-off-by: SuvarnaMeenakshi <sumeenak@microsoft.com>
Swap order of orchagent and portsyncd in start.sh and fix priorities
Many docker virtual switch tests are failing at the moment because orchagent never finishes initializing. After doing some searching I figured out that Ethernet24 is never published to State DB, which is reminiscent of #4821
Signed-off-by: Danny Allen <daall@microsoft.com>
* Bring up FPGA ports and test it
* Bring up those ports in neighbors dict
* Revert delete of a line
* Add test
* change code comment
* Change test name
* Revert submodule update
* src/sonic-utilities 9700e45...621aad0 (9):
> [Python] Migrate applications/scripts to import sonic-py-common package (#1008)
> [config qos] QoS and Buffer config genration for multi ASIC platforms (#978)
> [cli]: pass db connector as click context (#1029)
> [PDDF] Make utilities compatible to platform API 2.0, in accordance with pddf_2.0 (#940)
> [tests] Add unit tests for 'show platform ...' commands (#1021)
> Add secure fast/warm-reboot support for Aboot (#994)
> [sonic-installer] Create Envvars File for Incoming Image (#1011)
> [config load]: do not stop/reset/reload service if it is disabled (#1028)
> [tests]: move feature_test.py into tests folder (#1027)
* src/sonic-ztp c959371...dd025bc (2):
> Update all references to new 'sonic-installer' file name (#18)
> Filter out non-printable characters read from syseeprom (#17)
Removes installation of kube-proxy (117 MB) and flannel (53 MB) images from Kubernetes-enabled devices. These images are tested to be unnecessary for our use case, as we do not rely on ClusterIPs for Kubernetes Services or a CNI for pod networking.
* src/sonic-platform-common be1cc24...f3f3573 (3):
> Remove sonic-config-engine dependency from setup.py (#109)
> Migrate from sonic-daemon-base package to sonic-py-common package (#103)
> [Cables] Add support for 'Extended Specification Compliance' for QSFP cables (#108)
> [sfputilbase.py] Add application_advertisement NA field to transceiver_info_dict for platform api 1.0 (#104)
* src/sonic-platform-daemons 49d145c...8e0704e (1):
> Proper fix for thermalctld using sonic-py-common (#80)
> Fix thermalctld tests which were broken by the transition to sonic-py-common (#79)
> Migrate from sonic-daemon-base package to sonic-py-common package (#74)
summary of E530 platfrom:
- CPU: CTC5236, arm64
- LAN switch chip set: CENTEC CTC7132 (TsingMa). TsingMa is a purpose built device to address the challenge in the recent network evolution such as Cloud computing. CTC7132 provides 440Gbps I/O bandwidth and 400Gcore bandwidth, the CTC7132 family combines a feature-rich switch core and an embedded ARM A53 CPU Core running at 800MHz/1.2GHz. CTC7132 supports a variety of port configurations, such as QSGMII and USXGMII-M, providing full-rate port capability from 100M to 100G.
- device E530-48T4X: 48 * 10/100/1000 Base-T Ports, 4 * 10GE SFP+ Ports.
- device E530-24X2C: 24 * 10 GE SFP+ Ports, 2 * 100GE QSFP28 Ports.
add new files in three directories:
device/centec/arm64-centec_e530_24x2c-r0
device/centec/arm64-centec_e530_48t4x_p-r0
platform/centec-arm64
Co-authored-by: taocy <taocy2@centecnetworks.com>
Co-authored-by: Gu Xianghong <gxh2001757@163.com>
Co-authored-by: shil <shil@centecnetworks.com>
1. remove container feature table
2. do not generate feature entry if the feature is not included
in the image
3. rename ENABLE_* to INCLUDE_* for better clarity
4. rename feature status to feature state
5. [submodule]: update sonic-utilities
* 9700e45 2020-08-03 | [show/config]: combine feature and container feature cli (#1015) (HEAD, origin/master, origin/HEAD) [lguohan]
* c9d3550 2020-08-03 | [tests]: fix drops_group_test failure on second run (#1023) [lguohan]
* dfaae69 2020-08-03 | [lldpshow]: Fix input device is not a TTY error (#1016) [Arun Saravanan Balachandran]
* 216688e 2020-08-02 | [tests]: rename sonic-utilitie-tests to tests (#1022) [lguohan]
Signed-off-by: Guohan Lu <lguohan@gmail.com>
* Moving BRCM SAI from 3.7.5.1-1 to 3.7.5.1-2 to pick up the stubbed SAI API that were present in the header but missing in SAI implementation that cause link error during build.
In SAI header 1.5.2 there are defined SAI APIs such as "sai_query_attribute_capability()" and few other APIs that were missing the stub code in BRCM 3.7.5.1 SAI code delivery. This causes linking issue during build when we implemented the common handler to support "sai_query_attribute_capability()" that other platform supports. The expectation is that all SAI vendors must implement all the SAI header defined SAI APIs by stubbing those that they don't have the actual code support to return "SAI_STATUS_NOT_IMPLEMENTED". This allows common code for all platforms to be developed without having linking issue during build for all platforms. BRCM has provided the patch code and this PR moves the BRCM SAI from 3.7.5.1-1 to 3.7.5.1-2 to pick up those missing stubbed SAI APIs.
See BRCM case CS00010790550 for more details
Applications running in the host OS can read the platform identifier from /host/machine.conf. When loading configuration, sonic-config-engine *needs* to read the platform identifier from machine.conf, as it it responsible for populating the value in Config DB.
When an application is running inside a Docker container, the machine.conf file is not accessible, as the /host directory is not mounted. So we need to retrieve the platform identifier from Config DB if get_platform() is called from inside a Docker
container. However, we can't simply check that we're running in a Docker container because the host OS of the SONiC virtual switch is running inside a Docker container. So I refactored `get_platform()` to:
1. Read from the `PLATFORM` environment variable if it exists (which is defined in a virtual switch Docker container)
2. Read from machine.conf if possible (works in the host OS of a standard SONiC image, critical for sonic-config-engine at boot)
3. Read the value from Config DB (needed for Docker containers running in SONiC, as machine.conf is not accessible to them)
- Also fix typo in daemon_base.py
- Also changes to align `get_hwsku()` with `get_platform()`
- Created the VS setup to test DPB functionality
- Created "platform.json" for VS docker
- Added test case for Breakout CLI
Signed-off-by: Sangita Maity <sangitamaity0211@gmail.com>
[xcvrd] Fix bailing out on platforms that do not support QSFP-DD (#78)
Fix psud and test_thermalctld (#75)
[Thermal] Fix for 'show platform fan' command (#71)
Signed-off-by: Volodymyr Boyko <volodymyrx.boiko@intel.com>
As part of consolidating all common Python-based functionality into the new sonic-py-common package, this pull request:
1. Redirects all Python applications/scripts in sonic-buildimage repo which previously imported sonic_device_util or sonic_daemon_base to instead import sonic-py-common, which was added in https://github.com/Azure/sonic-buildimage/pull/5003
2. Replaces all calls to `sonic_device_util.get_platform_info()` to instead call `sonic_py_common.get_platform()` and removes any calls to `sonic_device_util.get_machine_info()` which are no longer necessary (i.e., those which were only used to pass the results to `sonic_device_util.get_platform_info()`.
3. Removes unused imports to the now-deprecated sonic-daemon-base package and sonic_device_util.py module
This is the next step toward resolving https://github.com/Azure/sonic-buildimage/issues/4999
Also reverted my previous change in which device_info.get_platform() would first try obtaining the platform ID string from Config DB and fall back to gathering it from machine.conf upon failure because this function is called by sonic-cfggen before the data is in the DB, in which case, the db_connect() call will hang indefinitely, which was not the behavior I expected. As of now, the function will always reference machine.conf.
use lsb_release -cs to get build env within the docker
for jessie: jessie
for stretch: stretch
for buster: buster
Signed-off-by: Guohan Lu <lguohan@gmail.com>
following command add additional mount in the sonic:
DOCKER_BUILDER_USER_MOUNT=/data2:/data2,/data:/data make sonic-slave-bash
Signed-off-by: Guohan Lu <lguohan@gmail.com>
* [platform] Add Support For Environment Variable
This PR adds the ability to read environment file from /etc/sonic.
the file contains immutable SONiC config attributes such as platform,
hwsku, version, device_type. The aim is to minimize calls being made
into sonic-cfggen during boot time.
singed-off-by: Tamer Ahmed <tamer.ahmed@microsoft.com>
