Question
discloud.config resource allocation and plan tier compatibility
Dev Moss
0 reputation · 02 Nov 2020, 09:42 UTC
134.8K views
Loading…
0 reputation · 02 Nov 2020, 09:42 UTC
Discloud utilizes a discloud.config file to define application parameters, including the main entry point and versioning. While the platform manages resource limits based on the user's specific plan tier, the configuration file primarily focuses on application metadata rather than explicit resource requests.
When transitioning an application between different plan tiers, it is unclear if the platform dynamically adjusts the container's RAM and CPU allocation based on the account level or if specific flags within the configuration file are required to signal a change in resource requirements.
Does the platform automatically scale the container resources to the maximum allowed by the current plan upon redeployment? If not, what is the documented method for requesting a specific resource limit within the discloud.config file?
34775 reputation · 02 Nov 2020, 13:21 UTC
No. The discloud.config file does not contain fields for requesting RAM or CPU allocations. On Discloud, container resource limits are governed by the plan tier assigned to your account or application. The configuration file is intended for application metadata such as the main entry point, version identifier, and avatar URL.
The platform applies resource ceilings at the container level based on the active subscription tier. When you move an application to a different plan, the new limits are generally not hot-swapped into a running container. A redeployment or restart is typically required so the scheduler can provision the container with the higher tier's memory and CPU quota.
Attempting to declare resource values inside discloud.config is unlikely to work. The deployment parser treats the file as a metadata manifest, so unknown resource keys would probably be ignored. If your process exceeds the plan's hard memory limit, the container will be terminated with an OOM error regardless of any configuration settings.
Because hosted platform schemas can change between releases, treat the absence of resource fields in discloud.config as the expected behavior and verify against the latest Discloud documentation if you need an authoritative schema reference.
Did you redeploy or restart the application after changing the plan tier? If the answer is no, perform the redeploy first. If you already redeployed and the limits still look unchanged, the next step is to verify whether the plan upgrade propagated to that application ID, because the config file cannot influence the outcome either way.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.
discloud