Problem/Justification
Managing resource allocations for applications is currently an all-or-nothing endeavor; the entire stack receives the same resource limits on each container regardless of the actual needs for those containers. This works for very simple applications with few (or very similar) containers.
However, many applications are separated into containers with very different resource needs. Assigning 8GB of RAM to immich shouldn’t result in 4 containers with 8GB limits; which actually results in up to 32GB of potential RAM usage.
If users were able to (optionally) configure resources per container, similarly to the way that labels can be applied to each container, we would have better control over the resource limits in our systems.
An even more user-friendly solution would be to allow developers to specify how to allocate portions of the current stack-scoped resource limits per container. Sticking with my previous example, immich might want 50% of the RAM to go to their primary container, 25% to machine learning, and the remainder split between the ancillary containers.
Impact
If manual per-container resource limits are implemented; a user would only be affected if they choose to manually specify resource allocations. If they do, the user would be able to more accurately allocate resources.
If the developer specification idea is implemented; a user would only need to know the total recommended values and the app manifest would handle splitting the resources. If a developer has not specified how to allocate resources, the app would be provisioned as it is today.
User Story
If manual allocations, a user would be able to add container-specific allocations much the same as labels; a list of CPU and memory allocations with a dropdown to select the container.
If developer specification, a user would not change how they allocate, though it may be useful to display the resulting allocations in a collapsible panel so users are aware.