Compose: Why does the v3 format apparently cripple the use of limits when not using docker stack?

[etc0de]

After taking a quick initial look at docker stack, it seemed to me that docker stack deploy no longer allows to easily start/stop individual services in a docker-compose.yml easily but just the group as a whole. If that is true, it seems that would naturally make it a bad match for various environments (and a good for others, but the point is that not everyone is going to be able to easily use it in their workflow instead of up -d/down on individual services as before).

However, for some reason v3 seems to abandon people relying on the old, more flexible model who still need memory and/or cpu limits entirely. Is that intentional or an oversight?

[jeanpralo]

From: https://docs.docker.com/compose/compose-file/compose-versioning/#version-2x-to-3x

cpu_shares, cpu_quota, cpuset, mem_limit, memswap_limit: These have been replaced by the resources key under deploy. Note that deploy configuration only takes effect when using docker stack deploy, and is ignored by docker-compose.

This behavior seems to be pushing people to use swarm, but definitely agree with @JonasT why couldn't we have both system working alongside ?

[shin-]

This seems to essentially be the same question as #4513. v2 and v3 will co-exist for the foreseeable future, so please feel free to use whichever one provides the most value to you.

[VeeeneX]

@jeanpralo I agree it should be moved to under service

[olejorgenb]

So it's not possible to configure cpu_shares when using swarm?