services should be scaled by default
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Landscape Charm |
Fix Released
|
Medium
|
Данило Шеган | ||
Bug Description
Currently, the scale factor of all services is 1 on the landscape machine. Not only is this a waste of resources (even on small machines), it also leaves us exposed to bugs in two services proxied under the same frontend from haproxy, and is a known scaling bottleneck of landscape (with no real known drawback to increasing).
It would be good to at least expand this to '2' for the message server.
Even better, I would suggest putting in a simple scaling algorithm in place with a cut off of 4 process or something.
like floor(2,
where x is int(ncpu/1.5) with a (! is_container()) safeguard or something.
This is conservative, yet at least attempts to scale to larger machines in some way.
We can then test on real deployments with data and see how the algorithm works.
there is a pattern for this in the stable charm that worked well for us as well, if you want to look there.
Related branches
- Chris Glass (community): Approve
- 🤖 Landscape Builder: Approve (test results)
- Free Ekanayaka (community): Approve
-
Diff: 325 lines (+81/-29)7 files modifiedhooks/lib/relations/haproxy.py (+27/-11)
hooks/lib/relations/tests/test_haproxy.py (+23/-11)
hooks/lib/services.py (+9/-2)
hooks/lib/tests/sample.py (+5/-0)
hooks/lib/tests/test_services.py (+4/-2)
hooks/lib/tests/test_templates.py (+11/-1)
templates/landscape-server (+2/-2)
| tags: | removed: kanban |
| Changed in landscape-charm: | |
| assignee: | nobody → Данило Шеган (danilo) |
| Changed in landscape-charm: | |
| importance: | Undecided → Medium |
| Changed in landscape-charm: | |
| status: | New → In Progress |
| Changed in landscape-charm: | |
| status: | In Progress → Fix Committed |
| Changed in landscape-charm: | |
| status: | Fix Committed → Fix Released |
