Hi. I've seen several bug reports and workarounds for charms that need to tune memory settings, which tends to fail horribly when using the local provider or deploying to lxc containers. It seems to be impossible to infer how much RAM a service should be using. The end result is extra configuration items override inferred values, and non-lxc specific code paths.
I'm not sure what the solution should be. Are there suitable container constraints that could be passed to the charm, and charms make their decisions based on the constraints rather than using the global system values and hoping there is only a single container on the system? Should the lxc containers be setup with limited resources and be reporting that, instead of the system values? Memory is the one I've seen tripped over several times. I also lxc specific code paths for disabling swap and messing with sysctl settings, but these are less common and don't cause your system to grind to a halt when you are testing a charm locally and your desktop gets swapped out. -- Stuart Bishop <[email protected]> -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
