> > > 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. >
The problem of lxd controllers using 50% -1GB (the default for wild tiger mongo engine) of the host ram should fall into this category of use cases. - "don't use more than X gigs of ram" https://docs.mongodb.com/manual/core/wiredtiger/#memory-use > > 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
