Memory constraints and lxc containers

[Stuart Bishop]

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 <stuart.bishop at canonical.com>