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. However, in Juju's case, we expect constraints to be minimums, so that we know the unit on that machine will have enough RAM to function (e.g. "give me a machine with at least 2GB of RAM, since I know my application won't work well with less"). This impedance mismatch is tricky to untangle. With a naive implementation of Juju constraints for lxd as a straight up setting of lxd limits, then you can add a lxd container and specify a memory constraint that is higher than the host machine's memory, and lxd will happily let you do that.... because it knows that container won't exceed that amount of memory (by definition it cannot). But it means that juju will then let you deploy a unit that needs more memory than the container has access to. Note that this is also the case for setting cores. On my local lxd environment I can juju add-machine --constraints cores=48 and the container will be created just fine. I'm not really sure how to resolve this problem. Maybe it's not a problem. Maybe constraints just have a different meaning for containers? You have to specify the machine number you're deploying to for any deployment past the first anyway, so you're already manually choosing the machine, at which point, constraints don't really make sense anyway. -Nate
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
