Memory constraints and lxc containers

[Mark Shuttleworth]

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.

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