- Introduction
- CLI Test Cases
- APIs for module base added for chassis
- APIs for chassis base added for modular chassis
- APIs for power consumption and supply APIs for modular chassis
- APIs for thermal added for modular chassis
- APIs for fan_drawer added for modular chassis
This test plan ONLY covers the changes associated with PRs below:
- Configure and show for platform chassis_modules #1145
- CHASSIS_STATE_DB on control-card for chassis state #395
- PSUd changes to compute power-budget for Modular chassis #104
- Introduce APIs for modular chassis support #124
- Common power consumption and supply APIs for modular chassis #136
- Thermalctld APIs for recording min and max temp #131
- Modular Chassis - Midplane monitoring APIs #148
- Modular-Chassis: Show midplane status #1267
| Term | Description |
|---|---|
| VOQ | Virtual Output Queue |
| PSU | Power Suppy Unit |
| SFM | Switch Fabric Card |
The following are useful commands for validating the testcases that follow.
- Use redis cli dump config db using
redis-dump -d 4 -y -k "*CHASSIS*"after shutdown line card, for example
admin@sonic:~$ redis-dump -d 4 -y -k "*CHASSI*"
{
"CHASSIS_MODULE|LINE-CARD1": {
"expireat": 1602657677.581144,
"ttl": -0.001,
"type": "hash",
"value": {
"admin_status": "down"
}
}
}
- Use redis cli to dump state Db
redis-dump -d 6 -y -k "*CHASSIS*", for example:
"CHASSIS_MODULE_TABLE|LINE-CARD1": {
"expireat": 980474761.732194,
"ttl": -0.001,
"type": "hash",
"value": {
"desc": "imm36-400g-qsfpdd",
"oper_status": "down",
"slot": "1"
}
}
- Use redis dump
redis-dump -d 6 -y -k "*MIDPLANE*"to get database information, for example:
redis-dump -d 6 -y -k "*MIDPLANE*"
{
"CHASSIS_MIDPLANE_TABLE|SUPERVISOR0": {
"expireat": 1551352416.7598891,
"ttl": -0.001,
"type": "hash",
"value": {
"access": "True",
"ip_address": "10.0.0.16"
}
}
}
- Use command
show chassis-modules statusto get status of modular chassis
- Supervisor
- Line card
On Supervisor:
show chassis-module status
Name Description Physical-Slot Oper-Status Admin-Status
------------ ------------------------------- --------------- ------------- --------------
FABRIC-CARD0 SFM1 17 Online up
FABRIC-CARD1 SFM2 18 Online up
FABRIC-CARD2 SFM3 19 Online up
FABRIC-CARD3 SFM4 20 Online up
FABRIC-CARD4 SFM5 21 Online up
FABRIC-CARD5 SFM6 22 Online up
LINE-CARD0 line-card 1 Empty up
LINE-CARD1 imm36-400g-qsfpdd 2 Online up
LINE-CARD2 line-card 3 Empty up
LINE-CARD3 imm32-100g-qsfp28+4-400g-qsfpdd 4 Online up
LINE-CARD4 line-card 5 Empty up
LINE-CARD5 imm32-100g-qsfp28+4-400g-qsfpdd 6 Online up
LINE-CARD6 line-card 7 Empty up
LINE-CARD7 line-card 8 Empty up
SUPERVISOR0 cpm2-ixr 16 Online up
on line card:
show chassis-modules status
Name Description Physical-Slot Oper-Status Admin-Status
----------- ------------------------------- --------------- ------------- --------------
LINE-CARD5 imm32-100g-qsfp28+4-400g-qsfpdd 6 Online up
SUPERVISOR0 cpm-ixr 16 Online up
- Verify output on supervisor shows 'up' for operational and admin state for supervisor, all line cards, all fabric cards for DUT.
- Verify output of each line card shows 'up' for operational state admin state for itself and supervisor for DUT
- Shutdown line card use Run command
sudo config chassis-modules shutdown <card> - Startup line card use Run command
sudo config chassis-modules startup <card>
- Supervisor
- Line Cards
- Verify
show chassis-modules statusreport line-card down after shutdown on supervisor
sudo config chassis-modules shutdown LINE-CARD1
admin@sonic:~$ show chassis-modules status LINE-CARD1
Name Description Slot Oper-Status Admin-Status
------------- ----------------- ------ ------------- --------------
LINE-CARD1 imm36-400g-qsfpdd 1 down down
- Verify
show chassis-modules statusreport line-card up after startup on supervisor for example:
sudo config chassis-modules startup LINE-CARD1
admin@sonic:~$ show chassis-modules status LINE-CARD1
Name Description Slot Oper-Status Admin-Status
------------- ----------------- ------ ------------- --------------
LINE-CARD1 imm36-400g-qsfpdd 1 Online up
show chassis-modules statusreport card status unchanged after shutdown on line card
- Use command
show chassis-modules midplane-statusto get status of midplane in modular chassis
- Supervisor
- Line Card
on Supervisor:
show chassis-modules midplane-status
Name IP-Address Reachability
---------- ------------ --------------
LINE-CARD0 10.0.0.1 True
LINE-CARD1 10.0.0.2 False
LINE-CARD2 10.0.0.3 True
LINE-CARD3 10.0.0.4 True
on line card:
Name IP-Address Reachability
----------- ------------ --------------
SUPERVISOR0 10.0.0.16 True
- Verify output on supervisor lists all the line cards, midplane ip addresses and reachability status as expected
- Verify on each Line Card supervisor reachability is correct and supervisor ip address is correct
- Run command “redis-dump -p 6380 -d 13 -y -k "TEMP" "on Supervisor
- Run command “redis-dump -d 6 -y -k "TEMP" on line card
- Supervisor
- Line Card
"TEMPERATURE_INFO_8|Thermal 7": {
"expireat": 1605120521.5682561,
"ttl": -0.001,
"type": "hash",
"value": {
"critical_high_threshold": "N/A",
"critical_low_threshold": "N/A",
"high_threshold": "105.0",
"low_threshold": "0.0",
"maximum_temperature": "127.0",
"minimum_temperature": "-2.0",
"temperature": "47.0",
"timestamp": "20190217 16:03:13",
"warning_status": "False"
}
- Verify on the supervisor, thermal sensor data for itself and all applicable peripherals. Also verify:
- High threshold is greater than maximum_temperature.
- Low threshold is lesser than the minimum_temperature.
- Warning status is False except check criteria high or low threshold above is false
- Verify on each line card that all sensor data is correct. Also verify:
- High threshold is greater than maximum_temperature.
- Low threshold is lesser than the minimum_temperature.
- Warning status is False except check criteria high or low threshold above is false
- Run command
redis-dump -d 6 -y -k "*power*" - Manually take one of the PSU offline
- Manually bring back PSU online
- Manually remove line card
- Manually insert back line card
- Manually remove one of the fan tray
- Manually insert back fan tray
- Supervisor
redis-dump -d 6 -y -k "*power*"
{
"CHASSIS_INFO|chassis_power_budget 1": {
"expireat": 1605209491.4552531,
"ttl": -0.001,
"type": "hash",
"value": {
"": "",
"Consumed Power FABRIC-CARD0": "370",
"Consumed Power FABRIC-CARD1": "370",
"Consumed Power FABRIC-CARD2": "370",
"Consumed Power FABRIC-CARD3": "370",
"Consumed Power FABRIC-CARD4": "370",
"Consumed Power FABRIC-CARD5": "370",
"Consumed Power FanTray0": "500",
"Consumed Power FanTray1": "500",
"Consumed Power FanTray2": "500",
"Consumed Power LINE-CARD1": "1000",
"Consumed Power LINE-CARD7": "1000",
"Consumed Power SUPERVISOR0": "80",
"Supplied Power PSU7": "3000.0",
"Supplied Power PSU8": "3000.0",
"Supplied Power PSU9": "3000.0",
"Total Consumed Power": "5800.0",
"Total Supplied Power": "3000.0"
}
}
}
- Verify the supplied power is greater than 0 for each PSU. Verify total consumed power and total supplied power are correct.
- Verify the supplied power is = 0.0 for offline PSU after step 2
- Verify the supplied power is > 0 for PSU back online after step 3
- Verify when LINE CARD1 is shutdown by using config command, the consumed power is 0 for LINE_CARD1 and when it is started the consumed power is not 0
- Verify that when fan tray is removed, the consumed power is 0 and when fan tray is re-inserted it is not 0.
This set of test cases will verify expected value return API calls using HTTP server in DUT. These tests will use existing API infrastructure existing in platform_tests/api
- call get_name api to retrieve module name
api description :
get_name - Retrieves the name of the module prefixed by SUPERVISOR, LINE-CARD,FABRIC-CARD
- Supervisor
- Line Card
- Data returned is of correct type and appropriate for the specific platform and verified to fact where applicable (slot number , module type etc., True/False)
- Verify returned value is correct if called from supervisor should have supervisor in name, if line card should have line card prefix to slot name
- call get_description api to retrieve module description
api description :
get_description - A string, providing the vendor's product description of the module.
- Supervisor
- Line Card
- Verify data returned is of correct type and appropriate
- call get_type api to retrieve module type
api description :
get_type - A string, the module-type from one of the predefined types MODULE_TYPE_SUPERVISOR, MODULE_TYPE_LINE or MODULE_TYPE_FABRIC
- Supervisor
- Line Card
- Verify data returned is of correct type and appropriate
- verify module type is correct if called from supervisor should be type supervisor and line card for line card
- call get_slot api to retrieve module description
api description :
get_slot - An integer, indicating the slot number in the chassis
- Supervisor
- Line Card
- Verify data returned is of correct type and appropriate
- verify slot number , compare with facts
- call get_oper_status api to retrieve module description
api description :
get_oper_status- A string, the operational status of the module from one of the predefined status values: MODULE_STATUS_EMPTY, MODULE_STATUS_OFFLINE,MODULE_STATUS_FAULT, MODULE_STATUS_PRESENT or MODULE_STATUS_ONLINE
- Supervisor
- Line Card
- Verify data returned is of correct type and appropriate
- verify status is expected for that module
- Send reboot api to retrieve module description with correct predefined type MODULE_REBOOT_DEFAULT, MODULE_REBOOT_CPU_COMPLEX, or MODULE_REBOOT_FPGA_COMPLEX
api description :
reboot - bool: True if the request has been issued successfully, False if not
- Supervisor
- Line Card
- Verify data returned is of correct type and appropriate
- verify module is rebooted successfully
- Set admin state to down set_admin_state
- Set admin state to up set_admin_state
api description :
set_admin_state - bool: True if the request has been issued successfully, False if not.
- Supervisor
- Line Card
- Verify data returned is of correct type and appropriate
- verify set_admin_state down returns true, verify admin status is changed to down for module using get_status
- verify set_admin_state up returns true,verify admin status changed back to up after step 2 using get_status
- call get_maximum_consumed_power api to retrieve module description
api description :
get_maximum_consumed_power - A float, with value of the maximum consumable power of the component.
- Supervisor
- Line Card
- Verify data returned is of correct type and appropriate
- call get_midplane_ip api to retrieve module description
api description :
get_midplane_ip: a string, the IP-address of the module reachable over the midplane
- Supervisor
- Line Card
- Verify data returned is of correct type and appropriate
- verify ip is correct based on slot index
- call is_midplane_reachable api to retrieve module description
api description :
is_midplane_reachable: A bool value, should return True if module is reachable via midplane
- Supervisor
- Line Card
- Verify data returned is of correct type and appropriate
- Value is true for line card that is up
- Value is false for line card that is not up
- get_module_index api method from chassis_base
api description :
get_module_index: An integer, the index of the ModuleBase object in the module_list
- Supervisor
- Line Card
- Verify data returned is of correct type and appropriate
- Verify Module index is correct for each module , get modules present from get_all_modules
- get_supervisor_slot api method from chassis_base
api description :
get_supervisor_slot: An integer, the vendor specific physical slot identifier of the
supervisor module in the modular-chassis
- Supervisor
- Line Card
- Verify data returned is of correct type and appropriate
- Verify slot index return is correct for superovisor card in chassis facts
- get_my_slot api method from chassis_base
api description :
get_my_slot - Returns an integer and vendor specific slot identifier
- Supervisor
- Line Card
- Verify data returned is of correct type and appropriate
- Verify slot index return is correct compare value from chassis facts
- get is_modular_chassis api method from chassis_base
api description :
is_modular_chassis - A bool value, should return False by default or for fixed-platforms. Should return True for supervisor-cards, line-cards etc running as part of modular-chassis
- Supervisor
- Line Card
- Verify data returned is of correct type and appropriate and true for chassis
- get get_maximum_supplied_power api method from psu_base
api description :
get_maximum_supplied_power -A float number, the maximum power output in Watts, e.g. 1200.1
- Supervisor
- Verify data returned is of correct type and appropriate and true for chassis
- Verify for each PSU from chassis facts a valid value is returned
- get get_status_master_led api method from psu_base (if supported by platform)
api description :
get_status_master_led - A string, one of the predefined STATUS_LED_COLOR_* strings.
- Supervisor
- Verify data returned is of correct type and appropriate and true for chassis
- Verify valid LED color predefined is returned and is as expected
- set set_status_master_led api method from psu_base to red (if supported by platform)
- set set_status_master_led api method from psu_base to green (if supported by platform)
api description :
set_status_master_led - bool: True if status LED state is set successfully, False if not
- Supervisor
- Verify data returned is of correct type and appropriate and true for chassis
- Verify for master LED color can be set to red using get_status_master_led, Manual step : physical led is changed to red
- Verify for master LED is set to green using get_status_master_led, Manual step : physical led is changed to red
- get_minimum_recorded api on each thermal sensor for given device
api description :
thermal_base:
get_minimum_recorded- A float number, the minimum recorded temperature of thermal in Celsius up to nearest thousandth of one degree Celsius, e.g. 30.125
- Supervisor
- Line Card
- Values are type float and returns applicable value
- Verify each sensor returns a valid value for all modules
- get_maximum_recorded api on each thermal sensor for given device
api description :
thermal_base:
get_maximum_recorded - A float number, the maximum recorded temperature of thermal in Celsius up to nearest thousandth of one degree Celsius, e.g. 30.125
- Supervisor
- Line Card
- Values are type float and returns applicable value
- Verify each sensor returns a valid value
- Add this new api tests to script tests/api/test_thermal.py
- get_maximum_consumed_power for each fan
api description :
get_maximum_consumed_power - A float, with value of the maximum consumable power of the component.
- Supervisor
- Values are type float and returns applicable values
- verify value returned for each fan is valid