Custom Templates are not loading on Secure Cloud
I have some templates that are running without issue on Community Cloud but None of them work on Secure Cloud.
And probably Serverless is suffering with the same issue as my custom endpoint do not load.
Issue affects A5000 GPU, on Secure Cloud.
Can someone please take a look:
- Issue is, on start.sh I have a Github repo update on loading container, it says that /workspace/repository does not exists
- the same template and start.sh works perfectly on Community Pods
Output from Pod Log:
Updating ComfyUI repository...
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
Failed to fetch from origin
- no issues with the repository, or access or related
- possible POD connection issues? Local files system issues?
We are testing a product.
7 Replies
Secure Cloud PODs are still not saving the /workspace volume.
As you init the POD the Workspace is empty, is someone having the same issue?
Even, COPY files are deleted.
This is impacting SERVERLESS for sure.
you have to rsync the files, secure cloud uses network storage and copy doesn't work the same, @ashleyk has examples in his workers if you look at this templates
AH ok, I though I've done something wrong, thanks @flash-singh
Is this the pre-start.sh you are saying? https://github.com/runpod/containers/blob/main/official-templates/stable-diffusion-comfyui/pre_start.sh
Are these the latest I can use as example? @ashleyk
GitHub
containers/official-templates/stable-diffusion-comfyui/pre_start.sh...
🐳 | Dockerfiles for the RunPod container images used for our official templates. - runpod/containers
Yes, and look at start.sh as well
Those are RunPod ones though not mine
thanks @ashleyk !
Just to confirm, Serverless PODs are not affected by this structure like Secure Cloud right?
What structure are you referring to?
There isn't serverless pods, there are serverless containers. Serverless and pods are 2 different things.
ok, I though the serverless used the same structure because I've got a similar issue, could be just coincidence.
Good to know, thanks @ashleyk