On Thu, Jan 12, 2017 at 11:20 AM, Nate Finch <nate.fi...@canonical.com> wrote:
> I'm implementing constraints for lxd containers and provider... and > stumbled on an impedance mismatch that I don't know how to handle. > > It seems as though lxd limits (what in juju we would call constraints) are > implemented as maximums, not minimums. For containers sharing a host, this > makes sense. If you say "don't use more than 2 gigs of ram" then you know > the max that container will use, and thus how much leftover you can expect > the host to have for other containers. > > Is the second part (how much leftover you can expect the host to have for other containers) captured somewhere? Because it seems to me that the important question Juju needs to be asking is, "how over-provisioned is the host I'm about to deploy on?", so that containers can be intelligently load-balanced across the infrastructure. Assuming Juju has full control over the hosts it is deploying containers onto[2], I think one thing to do might be to allow the admin to specify ratios (maybe separate for each of CPU, RAM, disk) to indicate how over-provisioned to allow hosts and containers to be to be. Let's take as an example a host with 16 GB of RAM, where you want to deploy 16 containers with a constraint of "at least 1G of RAM". There could be two relevant over-provisioning ratios: one to specify how over-provisioned a container hypervisor can be, and the other to specify how much more RAM than the constraint specifies the container can be allowed to use. This idea is perhaps a little naive; I'm not sure where one would specify these values. If that sounds confusing, maybe it's easier to look at an example[1]: Host RAM (GB) Minimum RAM Constraint (GB) Host Over-provisioning Ratio Container Over-provisioning Ratio Allowed number of containers for host RAM Limit per Container (GB) 16 2 1.00 1.00 8 2 16 1 1.00 1.00 16 1 16 1 2.00 1.00 32 1 16 1 1.00 2.00 16 2 16 1 2.00 2.00 32 2 16 1 2.00 4.00 32 4 16 1 16.00 4.00 256 4 16 1 16.00 1.00 256 1 Regards, Mike [1]: https://docs.google.com/spreadsheets/d/1j6-98nB5AA_viHK9nF42MPpbZf35wv2N2gDi8DrhepU/view [2]: (so that the numbers aren't thrown off by other juju deployments, or non-juju deployments to the same hypervisor)
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
