allow optional gpu reservation in docker-compose.yaml

[alita-moore]

Description

I have a compose file that I use for development

services:
workstation: 
    ...
    deploy:
      resources:
        reservations:
            devices:
              - driver: nvidia
                count: 1
                capabilities: [gpu]

I do development from inside the dev container. I allow this container to have access to the gpu. But I am running this on AWS EC2, so to save money I often want to run the container without a gpu. The following config works when there is no gpu:

services:
workstation: 
    ...
    deploy:
      resources:
        reservations:
            devices:
              - driver: nvidia
                count: 0
                capabilities: [gpu]

However, if I forget to set this to 0 my container fails to start on the new machine without a GPU.

Is there a way to allow for the container to use the GPU if one is available, and if one is not then it will run as if the count were set to 0?

This would make it easier to use gpu in our development environment because we wouldn't have to remember to change the count value before changing the machine type.

[ndeloof]

By nature compose is "imperative", i.e. configuration doesn't adapt to platform constraints with an alternative config.
For such use-case, the common practice is to have a main compose.yaml file and to use a production-specific compose-prod.yaml override file that will be used during deployment - in most case using a script, so the override is always applied.

[alita-moore]

can you add the ability to set the count to be 0 or 1? i.e.

count:
  - 0
  - 1

would that still be imperative? Thank you for your help :)

[ndeloof]

"imperative" maybe was not he right word for what I mean: maybe "deterministic" better describes.
i.e. if your compose model declares requirement for GPU, there's no "best effort" or "optional" option here. The compose model MUST declare resources to be allocated. If those aren't available, compose will fail, without a fallback.

Again, the recommended approach for your use-case is to make it explicit with an override file there's an alternative way to run the application for a specific environment.
I'm closing this issue as "not planned"