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 -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
