Bug #62050


High volume of reimage failures in teuthology suites

Added by Laura Flores 9 months ago. Updated 8 months ago.

% Done:


3 - minor
Affected Versions:
Crash signature (v1):
Crash signature (v2):


Description of problem

There is a high volume of reimaging failures in teuthology suites. For instance, "Error reimaging machines: Expected smithi172's OS to be ubuntu 20.04 but found centos 8 " and "Error reimaging machines: Cannot connect to remote host smithi097".

How to reproduce

Run some jobs in a teuthology suite- rados, rbd, etc.

Time noticed / Event Window (in UTC)

First reported by Yuri on July 14th, 7:21 AM UTC. The failures have been happening in intermittent time windows since.

In this panel, from July 14th to now, you can see spikes in reimage failures:

Actual results

High volume of reimage failures.

Expected results

Little to no reimage failures.

Additional analysis

I'm seeing a correlation between reimage failures: And load spikes:
Actions #1

Updated by Laura Flores 9 months ago

  • Copied from Bug #62049: High volume of reimage failures in teuthology suites added
Actions #2

Updated by Laura Flores 9 months ago

  • Copied from deleted (Bug #62049: High volume of reimage failures in teuthology suites)
Actions #3

Updated by Laura Flores 9 months ago

Linking a recent rados baseline as an example:

63/307 jobs (20%) were affected by reimage failures.

Actions #5

Updated by Zack Cerza 9 months ago

More reimaging failures today. This job saw ipmi seem to completely fail for one of the nodes:

2023-07-27T12:08:19.228 DEBUG:teuthology.orchestra.console:pexpect command: ipmitool -H -I lanplus -U inktank -P ApGNXcA7 power status
2023-07-27T12:08:20.337 DEBUG:teuthology.orchestra.console:check power output: 
2023-07-27T12:08:20.338 WARNING:teuthology.contextutil:'wait for power on' reached maximum tries (16) after waiting for 60.0 seconds

Would be great if we could get to the bottom of the IPMI issues
Edit: To be clear, I mean BMCs and/or switches. I don't believe it's e.g. a bug in ipmitool.

Actions #6

Updated by Zack Cerza 9 months ago

Not sure if anyone's looking at these, but this job had skipped reimages, failed ipmi, and "stale jobs detected":

Actions #7

Updated by Zack Cerza 9 months ago

Another "wrong OS" job:

The supervisor log:
The relevant bits:

2023-08-02T17:17:18.577 DEBUG:teuthology.provision.fog.smithi018:FOG request: GET /host {"name": "smithi018"}
2023-08-02T17:17:18.652 DEBUG:teuthology.provision.fog.smithi018:FOG request: GET /image {"name": "smithi_ubuntu_20.04"}
2023-08-02T17:17:18.694 DEBUG:teuthology.provision.fog.smithi018:Requesting image smithi_ubuntu_20.04 (ID 2)
2023-08-02T17:17:18.695 DEBUG:teuthology.provision.fog.smithi018:FOG request: PUT /host/124 {"imageID": 2}
2023-08-02T17:17:18.755 INFO:teuthology.provision.fog.smithi018:Scheduling deploy of ubuntu 20.04
2023-08-02T17:17:18.755 DEBUG:teuthology.provision.fog.smithi018:FOG request: GET /task/active None
2023-08-02T17:17:18.867 DEBUG:teuthology.provision.fog.smithi018:FOG request: GET /tasktype {"name": "deploy"}
2023-08-02T17:17:18.899 DEBUG:teuthology.provision.fog.smithi018:FOG request: POST /host/124/task {"taskTypeID": 1}

Note that the three other nodes in that job were reimaged correctly, and of course followed the exact same process.

The node's console log during the reimage process:
The relevant bits:

note: Storage Location, Image name smithi_rhel_8.6

Fog's reimaging log:
The relevant bits:

fog    smithi018    2023-08-02 07:44:18    2023-08-02 07:46:16    1 minute 58 seconds    smithi_ubuntu_20.04    Deploy
fog    smithi018    2023-08-02 17:19:03    2023-08-02 17:20:01    58 seconds    smithi_rhel_8.6    Deploy

smithi018's page:
The image is set to "smithi_rhel_8.6 - (5)"

So, we are requesting the correct image, but FOG simply ignores that for some reason.

Actions #8

Updated by Laura Flores 9 months ago

Since it's been long suspected that this is a network-related issue, we discussed in the last Infrastructure meeting the idea of adding additional monitoring (i.e. ICMP monitoring to help us prove whether the network is really at play here.

Plan for this TBD at the next Infrastructure meeting.

Actions #9

Updated by Zack Cerza 8 months ago

Saw a new (to me) problem yesterday. During a period of high failure rates, I saw several jobs had been "in line" for a reimage for over an hour. That's a FOG-ism where the machines have netbooted into FOG's reimage client, but FOG is too busy to serve them at the moment. I also found some "not enough children"-type messages in a PHP log, of all places, so I found and increased those settings.

Still, even during periods where there were no active reimages, these machines sat around and waited, and eventually their jobs failed after over five hours of waiting. An example:
The last lines from the console log:

 * Attempting to check in............................Failed
 * No Active Task found for Host: smithi181 (0c:c4:7a:88:7b:9d) (In line for 5:11:25)


Also available in: Atom PDF