mongodb v7.0.12

[h-vetinari]

Given that 6.0 is supported way longer than 6.1-6.3, I'm starting the catch-up with 7.0 here, so that we can create a branch for this even if we move on to 7.2 soon after.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[h-vetinari]

@conda-forge-admin, please rerender

[h-vetinari]

@jaimergp @isuruf
Not sure if this is expected for the cirun builds, but I've seen this now several times that a failed job does not properly finish (e.g. "Build on Linux" still has a turning yellow wheel), and more importantly, that the raw logs for that job are effectively empty:

2024-02-28T04:21:10.5308211Z Requested labels: cirun-openstack-cpu-large--8075232475-linux_aarch64_, linux, x64, self-hosted
2024-02-28T04:21:10.5308629Z Job defined at: conda-forge/mongodb-feedstock/.github/workflows/conda-build.yml@refs/pull/80/merge
2024-02-28T04:21:10.5308806Z Waiting for a runner to pick up this job...
2024-02-28T04:22:29.1192514Z Job is about to start running on the runner: cirun-conda-forge--mongodb-feedstock-fd6a0cc (repository)

In this case, this means I cannot even see the point of failure in the logs, and neither scrolling up nor the built-in search can uncover it. This is a pretty large usability hurdle, so I think we should figure out how to fix this?

[jaimergp]

If you go to the job summary (the Home link), you'll see:

The self-hosted runner: cirun-conda-forge--mongodb-feedstock-fd6a0cc lost communication with the server. Verify the machine is running and has a healthy network connection. Anything in your workflow that terminates the runner process, starves it for CPU/Memory, or blocks its network access can cause this error.

We have seen this in cupy-feedstock while running the tests because it had a memory leak and starved every other process, including the runner itself. We have given higher priority to the runner process itself so the OOM killer tries other processes first, but it looks like we still need to refine that config.

In short, your job is using too many resources. Either reduce parallelism or upgrade to a bigger runner. But I'm surprised mongodb takes more resources than pytorch.

I'll also open an issue in the open-gpu-server repo to track this, so at least we have a reference to point people to while we iterate on this (no eta promised though).

PS: The logs get lost if you access them after losing connection with the runner, but if you leave an open tab with the logs being streamed from the beginning, you'll be able to see them as long as you keep that tab open.

[jaimergp]

xref Quansight/open-gpu-server#28

[h-vetinari]

Thanks for the input, makes sense!

In short, your job is using too many resources. Either reduce parallelism or upgrade to a bigger runner. But I'm surprised mongodb takes more resources than pytorch.

It seems that the compilation failure somehow blows things up - the other two arches were running fine...?

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.