In the end, you say you want an instance with 2gb of ram and if the cloud has an instance with that exact limit it is in fact an exact limit. The key things here is the clouds don't have infinite malleable instance types like containers (this works for kvm and for lxd). So I'm not sure the mis-match is as far apart as it seems. root disk means give me a disk this big, if you ask for 2 core as long as you can match an instance type with 2 cores it's exactly the max you get.
It seems part of this can be more adjusting the language from "minimum" to something closer to "requested X" where request gives it more of a "I want X" without the min/max boundaries. On Fri, Jan 13, 2017 at 3:14 AM John Meinel <j...@arbash-meinel.com> wrote: > So we could make it so that constraints are actually 'exactly' for LXD, > which would then conform to both minimum and maximum, and would still be > actually useful for people deploying to containers. We could certainly > probe the host machine and say "you asked for 48 cores, and the host > machine doesn't have it". > > However, note that explicit placement also takes precedence over > constraints anyway. If you do: > juju deploy mysql --constraints mem=4G > today, and then do: > juju add-unit --to 2 > We don't apply the constraint limitations to that specific unit. Arguably > we should at *least* be warning that the constraints for the overall > application don't appear to be valid for this instance. > > I guess I'd rather see constraints still set limits for containers, > because people really want that functionality, and that we warn any time > you do a direct placement and the constraints aren't satisfied. (but warn > isn't failing the attempt) > > John > =:-> > > On Fri, Jan 13, 2017 at 10:09 AM, Stuart Bishop < > stuart.bis...@canonical.com> wrote: > > On 13 January 2017 at 02:20, 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. > > > > 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. > > > I don't think Juju can handle this. Either constraints have different > meanings with different cloud providers, or lxd needs to accept minimum > constraints (along with any other cloud providers with this behavior). > > If you decide constraints need to consistently mean minimum, then I'd > argue it is best to not pass them to current-gen lxd at all. Enforcing that > containers are restricted to the minimum viable resources declared in a > bundle does not seem helpful, and Juju does not have enough information to > choose suitable maximums (and if it did, would not know if they would > remain suitable tomorrow). > > -- > Stuart Bishop <stuart.bis...@canonical.com> > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
