| 2023-04-14 07:34:31 |
Alex Lutay |
description |
Hi,
It is a feature request which can help us in testing[1] and might be necessary in a real-life business[2].
TL;DR: juju constrants allow to limit hardware resources per application (unit/container).
By default no limits set (cores=0 mem=0M) for newly created models and newly started apps.
Currently, it is possible to set constraints for:
* application: juju deploy --constraints mem=1G mysql ...
* available model: juju set-model-constraints mem=1G [-m another_available_model]
* model 'controller' on bootstrap: juju bootstrap microk8s k8s --bootstrap-constraints mem=1G
It is not possible to define "default constraints" to all models created in the future.
This is a feature request to develop it. We call it "controller constraints" (could be "default constraints").
Unfortunately '--bootstrap-constraints' is applicable for model "controller" only (juju's mongodb, unit 0). And has no effect on all future models/apps. Documentation says:
https://juju.is/docs/olm/juju-bootstrap
> If --bootstrap-constraints is used, its values will also apply to any
> future controllers provisioned for high availability (HA).
>
> If --constraints is used, its values will be set as the default constraints for
> all future workload machines in the model, exactly as if the constraints were
> set with juju set-model-constraints.
We do not see a way to apply constraints on all the future models.
---
[1] Data platform team is testing charms on free GH runners with 8Gb RAM only.
Also charms have auto-tunning logic to allocate 50-75% RAM to MySQL DB (for top performance out of the box). The newly started LXC VMs (and K8s containers) shows the whole host server RAM availability to _every_ unit => staring 3 MySQL units on GH runner with 8GB RAM cause MySQL to allocate 3*(8GB*75%)=18GB RAM on 8GB server => it causes random OOM case, like:
https://github.com/canonical/operator/issues/844#issuecomment-1488268566
Having ability to limit each unit RAM usage to 1GB will help us,
as charm code will see 1GB availability only and will set MySQL innodb_buffer_pull_size="1GB*75%".
Also, lack of knowledge about "real/dedicated" or "shared" 8GB RAM is a problem for charm.py code.
---
[2] The real business do not like to start VMs/containers with unlimited resources by default.
Normally they set low limits, e.g. "core=2 mem=512M" and increase it for necessary VM/containers only. The Juju concept is "unlimited" resources by default + impossible to set limits for future models will create business troubles for highly loaded systems, where DB1.1 and DB2.1 units are started on the same physical server and greedy to allocate 75% RAM each.
Tnx! |
Hi,
It is a feature request which can help us in testing[1] and might be necessary in a real-life business[2].
TL;DR: juju constrants allow to limit hardware resources per application (unit/container).
By default no limits set (cores=0 mem=0M) for newly created models and newly started apps.
Currently, it is possible to set constraints for:
* application: juju deploy --constraints mem=1G mysql ...
* available model: juju set-model-constraints mem=1G [-m another_available_model]
* model 'controller' on bootstrap: juju bootstrap microk8s k8s --bootstrap-constraints mem=1G
It is not possible to define "default constraints" to all models created in the future.
This is a feature request to develop it. We call it "controller constraints" (could be "default constraints").
Unfortunately '--bootstrap-constraints' is applicable for model "controller" only (juju's mongodb, unit 0). And has no effect on all future models/apps. Documentation says:
https://juju.is/docs/olm/juju-bootstrap
> If --bootstrap-constraints is used, its values will also apply to any
> future controllers provisioned for high availability (HA).
>
> If --constraints is used, its values will be set as the default constraints for
> all future workload machines in the model, exactly as if the constraints were
> set with juju set-model-constraints.
We do not see a way to apply constraints on all the future models.
---
[1] Data platform team is testing charms on free GH runners with 8Gb RAM only.
Also charms have auto-tunning logic to allocate 50-75% RAM to MySQL DB (for top performance out of the box). The newly started LXC VMs (and K8s containers) shows the whole host server RAM availability to _every_ unit => staring 3 MySQL units on GH runner with 8GB RAM cause MySQL to allocate 3*(8GB*75%)=18GB RAM on 8GB server => it causes random OOM case, like:
https://github.com/canonical/operator/issues/844#issuecomment-1488268566
Having ability to limit each unit RAM usage to 1GB will help us,
as charm code will see 1GB availability only and will set MySQL innodb_buffer_pull_size="1GB*75%".
Also, lack of knowledge about "real/dedicated" or "shared" 8GB RAM is a problem for charm.py code.
Our current solution is to set manually:
> subprocess.check_output("juju set-model-constraints cores=2 mem=1G")
for every test (dedicated juju model), which is a human error proven.
---
[2] The real business do not like to start VMs/containers with unlimited resources by default.
Normally they set low limits, e.g. "core=2 mem=512M" and increase it for necessary VM/containers only. The Juju concept is "unlimited" resources by default + impossible to set limits for future models will create business troubles for highly loaded systems, where DB1.1 and DB2.1 units are started on the same physical server and greedy to allocate 75% RAM each.
Tnx! |
|
