I have run into several issues when starting multiple containers at once, particularly if the required version(s) of Foundry is/are not yet cached.
The container always authenticates with Foundry servers first, even if the required Foundry version is already cached.
With multiple containers starting up at the same time, you immediately run into rate limiting on Foundry’s side.
Authenticating with them is not required though, you could just use the cached installation file right away.
When multiple containers start at the same time and for the same Foundry version, they try to download the same file all at the same time.
Downloads always go into downloading.zip, then get renamed.
The temporary file here should have some unique name, so that multiple containers will not try writing to the same file at the same time; there might also be some way to make sure only a single download happens.
When containers with different Foundry versions download at the same time, you end up with installation files labeled for the wrong version of Foundry.
If you have more than a single version of Foundry downloading at the same time, you will end up with the wrong file. E.g. I had a 12.343 and a 13.351 starting up; the v13 got the short end of the straw, and I ended up with a 12.343 zip labeled as 13.351.
This should also be solved by unique temporary file names.
The workaround for problems 2 and 3 here is making sure there’s only ever a single container starting up at the same time if you are not sure all relevant versions are already cached, but that is quite tedious. There is a reason it’s all podman, managed by systemd :)
I have run into several issues when starting multiple containers at once, particularly if the required version(s) of Foundry is/are not yet cached.
The container always authenticates with Foundry servers first, even if the required Foundry version is already cached.
With multiple containers starting up at the same time, you immediately run into rate limiting on Foundry’s side.
Authenticating with them is not required though, you could just use the cached installation file right away.
When multiple containers start at the same time and for the same Foundry version, they try to download the same file all at the same time.
Downloads always go into
downloading.zip, then get renamed.The temporary file here should have some unique name, so that multiple containers will not try writing to the same file at the same time; there might also be some way to make sure only a single download happens.
When containers with different Foundry versions download at the same time, you end up with installation files labeled for the wrong version of Foundry.
If you have more than a single version of Foundry downloading at the same time, you will end up with the wrong file. E.g. I had a 12.343 and a 13.351 starting up; the v13 got the short end of the straw, and I ended up with a 12.343 zip labeled as 13.351.
This should also be solved by unique temporary file names.
The workaround for problems 2 and 3 here is making sure there’s only ever a single container starting up at the same time if you are not sure all relevant versions are already cached, but that is quite tedious. There is a reason it’s all podman, managed by systemd :)