lxd and constraints

[Merlijn Sebrechts]

A few thoughts that pop into my mind

Having constraints be "min requirements" on one and "max usage" on another
provider is an issue because this would mean bundles behave differently on
different clouds. Bundles should behave the same on all clouds to improve
portability and reduce vendor lock-in.

Specifying "max usage" constraints for LXD containers is something that's
very useful and the behavior you're describing seems logical for max
constraints. When the maximum constraint is more than the available
resources, then the container will never hit that constraint.

Maybe we can make the constraints clearer by making the difference between
min and max explicit? `--constraints cores=>4 cores=<12`.


2017-01-12 20:20 GMT+01:00 Nate Finch <nate.finch at canonical.com>:

> 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 at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20170112/00d69a31/attachment.html>