Memory constraints and lxc containers

[Stuart Bishop]

On 4 March 2015 at 14:28, Mark Shuttleworth <mark at ubuntu.com> wrote:
>
> I'd like to propose that we adopt a "minimum footprint by default"
> guidance for charmers, with a convention for how you might say "in this
> case, assume you're the dominant workload" or "feel free to use XYZ
> resources".
>
> By this I mean that a charm deployed with default config would adopt a
> lowest-cost posture by default. In the typical iterative development
> story, code is run 10x on a developer workstation for every time it goes
> to test, and possibly 10x in test for every time it goes to production.
> It makes sense therefore to have the charm behaviour with default
> configs reflect the more lightweight, evaluation-centric approach.

So the configuration defaults would be automatic tuning disabled, and
manual tuning defaults set for minimal usable? That can be done today.

An alternative would be for charms to specify their minimal VM
requirements, and have juju deploy provision a container with those
requirements unless overriden. Automatic tuning would remain the
default, assuming we get it to use the container constraints rather
than the host values. In the longer term, should we be aiming at this?

I'm not too worried about settings used for running scripted tests, as
the script can specify the minimal constraints. I've got the Cassandra
tests running with settings too low to be useful for development, and
made the default tunings a reasonable guess for a developer running a
local instance.

I think we will still need automatic tuning, so it would be nice to
have lxcfs or similar so that option can work with lxc containers.
PostgreSQL not having automatic tuning has always been a big problem
for the project.


> For example, if MySQL is being used as part of a product, most
> developers will run it locally with dummy data. There's unlikely to be a
> full production data dump on the developer workstation. So it would make
> sense for MySQL to be running in a lowest-footprint posture. In a test
> environment, we might run many services on one machine, but with more
> data. We're not concerned in test so much with performance as with
> correctness. So we might have a larger data set, but fewer units in the
> service, or slower units for scale-up bits. So in this case we might say
> "MySQL can use 2GB RAM in its container". And finally in production we
> might well place services individually in VMs with dedicated RAM, and
> expect the behaviour we have today, where that service dominates the
> resource utilisation in that VM.
>
> Ideally, there's a nice convention for the two non-default scenarios,
> and that convention is implemented in a lot of the glue bits which get
> reused across many different scenarios.
>
> Mark
>



-- 
Stuart Bishop <stuart.bishop at canonical.com>