[Bug]: devpi runs at 100% CPU and is unavailable for quite some time after container started

[timmc-edx]

Describe the bug that you are seeing.

After running make lms-up or similar, the devpi container burns CPU for about 20 minutes. (I think packages also cannot be installed in the LMS container during this, but something else may have been going on.)

According to devpi/devpi#737 this may be the result of devpi fetching and processing indexes. The suggested curl -H "Accept: application/json" http://localhost:3141/+status shows that the devpi_web_whoosh_index_queue_size metric is above zero (and slowly falling), which appears to confirm this theory.

As far as I am aware, no one uses the devpi UI, which I think is all the indexes are used for. So I think we may want to add --indexer-backend null to our docker image.

Not sure why this would have started recently, but I don't recall this happening until a month ago or so.

Did this happen on the host (your machine or the remote instance) or in the container?

container

Steps to reproduce.

No response

What system was this issue seen on?

Linux

[github-actions]

Follow-up checklist (for Arch-BOM usage)

• Is the issue flaky or consistent?
• Does it affect multiple people or multiple types of systems?
• Update the devstack troubleshooting documentation page if necessary
  • Do we need a new troubleshooting section?
  • Did a troubleshooting section already exist, but it wasn't easy to find given the symptoms?
  • If a recurring issue, should we ticket an automated resolution in place of the doc?

[timmc-edx]

I've tested this locally by modifying the devpi image to include --indexer-backend null in the entrypoint script and it seemed to work fine.

[timmc-edx]

Moving to blocked for now; we may end up getting rid of devpi entirely: #1137

[rgraber]

Closing in favor of #1137