Project

General

Profile

action #88514

[virtualization][ipmi] Test incomplete sometimes due to de-activate a already "deactivate" status SUT.

Added by XGWang0 6 months ago. Updated 5 months ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
Feature requests
Target version:
Start date:
2021-02-10
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Sometimes, the test is failed by incomplete, because ipmi backend executes deactivate operation on a "deactivate" status SUT.

Error info "Reason: backend died: ipmitool -I lanplus -H 10.67.135.44 -U root -P susetesting sol deactivate: Info: SOL payload already de-activated at /usr/lib/os-autoinst/backend/ipmi.pm line 65. "

Test case:http://openqa.qa2.suse.asia/tests/28722

History

#1 Updated by okurz 5 months ago

  • Project changed from openQA Infrastructure to openQA Tests
  • Subject changed from [IPMI] Test incomplete sometimes due to de-activate a already "deactivate" status SUT. to [virtualization][ipmi] Test incomplete sometimes due to de-activate a already "deactivate" status SUT.
  • Category set to Bugs in existing tests

This can at best be fixed in tests though. The problem only happens if the connection was already terminated in before.

#2 Updated by XGWang0 5 months ago

  • Project changed from openQA Tests to openQA Infrastructure
  • Category deleted (Bugs in existing tests)

okurz wrote:

This can at best be fixed in tests though. The problem only happens if the connection was already terminated in before.

Sometimes, the fix still need to be fixed in ipmi backend, eg SUT reboot operation, which ipmi backend will "reset" connection, this operation will invoke "ipmitool deactivate" and trigger this issue.

#3 Updated by okurz 5 months ago

  • Project changed from openQA Infrastructure to openQA Project
  • Category set to Feature requests
  • Priority changed from Normal to Low
  • Target version set to future

Well, I am not exactly sure if I understand you correctly. However I would agree that the ipmi backend can improve the error handling. That would be within the project "openQA Project" though. I doubt there is anything we can do from infrastructure side. So changing the project for the ticket accordingly.

Also available in: Atom PDF