Repository navigation
fix(deploy): round the memory and CPU limits to whole numbers - #1119
Conversation
|
/backport to stable35 |
|
/backport to stable34 |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Priority: ➖ Normal Merge Risk: ⚪ Minimal · up to
|
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
- Configuration used: Organization UI
- Review profile: CHILL
- Plan: Advanced
- Run ID:
38e3131a-720a-49c9-88b3-53b421c0c818
📒 Files selected for processing: 4
lib/DeployActions/DockerActions.phplib/DeployActions/KubernetesActions.phplib/Service/AppAPICommonService.phptests/php/Service/AppAPICommonServiceTest.php
Included review availability: This review used your included allowance. Your plan provides up to 2 included reviews per hour; 1 remain after this review.
Signed-off-by: Oleksandr Piskun <oleksandr2088@icloud.com>
cc9a044 to
0975efc
Compare
The daemon settings convert the CPU limit with
Number(cpus) * 1000000000, so some values come out with a fraction: 1.07 CPUs is stored as1070000000.0000001and 2.01 as2009999999.9999998(50 of the 1600 two-decimal values up to 16, among them 4.1 and 8.2). AppAPI sent the value on unchanged. On Docker every deploy and update on that daemon failed, because Docker does not accept a fraction and HaRP now refuses it before creating the container, and an update left the ExApp without a container, because the old one is removed first. On Kubernetes HaRP dropped the fractional value, so those ExApps ran without a CPU limit.AppAPI now rounds
memoryandnanoCPUsto whole numbers when it builds the deploy parameters for Docker (HaRP and Docker Socket Proxy) and Kubernetes, so it also works for limits that are already stored. Kubernetes ExApps on such a daemon get the configured CPU limit with their next deploy or update. Other values are passed on unchanged.