<div dir="ltr">+1</div><div class="gmail_extra"> <div class="gmail_quote">On Mon, Jan 16, 2017 at 9:28 AM, Aaron Bentley <<a href="mailto:aaron.bentley@canonical.com" target="_blank">aaron.bentley@canonical.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">ISTM that - constraints are used to ensure that a workload runs well. Minimum constraints serve this, and maximum constraints do not. (Maximum constraints may be useful to ensure that a workload does not swamp processes outside its container.) - Juju cannot enforce a minimum constraint. LXD could potentially add support for this, and then Juju would be able to leverage it. - Given that Juju cannot enforce a minimum constraint on LXD at this time, it would make sense to emit a warning that it is ignoring the constraint. This would retain the portability of bundles that use constraints while keeping the user informed. <div><div class="h5"> On 2017-01-13 01:14 PM, Nate Finch wrote: > I just feel like we're entering a minefield that our application and CLI > aren't really built to handle. I think we *should* handle it, but it > needs to be well planned out, instead of just doing a tiny piece at a > time and only figuring out later if we did the right thing. > > There's a few problems I can see: > > 1.) you can have 10 lxd containers with memory limit of 2GB on a machine > with 4GB of RAM. Deploying 10 applications to those containers that > each have a constraint of mem=2GB will not work as you expect. We could > add extra bookkeeping for this, and warn you that you appear to be > oversubscribing the host, but that's more work. > > 2.) What happens if you try to deploy a container without a memory limit > on a host that already has a container on it? > > For example: > 4GB host > 2GB lxd container > try to deploy a new service in a container on this machine. > Do we warn? We have no clue how much RAM the service will use. Maybe > it'll be fine, maybe it won't. > > 3.) Our CLI doesn't really work well with constraints on containers: > > juju deploy mysql --constraints mem=2G --to lxd > > Does this deploy a machine with 2GB of ram and a container with a 2GB > ram limit on it? Or does it deploy a machine with 2GB of ram and a > container with no limit on it? It has to be one or the other, and > currently we have no way of indicating which we want to do, and no way > to do the other one without using multiple commands. > > This is a more likely use case, creating a bigger machine that can hold > multiple containers: > juju add-machine --constraints mem=4GB > // adds machine, let's say 5 > // create a container on machine 5 with 2GB memory limit > juju deploy mysql --constraints mem=2GB --to lxd:5 > > At least in this case, the deploy command is clear, there's only one > thing they can possibly mean. Usually, the placement directive would > override the constraint, but in this case, it does what you would > want... but it is a littler weird that --to lxd:5 uses the constraint, > but --to 5 ignores it. > > Note that you can't just write a simple script to do the above, because > the machine number is variable, so you have to parse our output and then > use that for the next command. It's still scriptable, obviously, but > it's more complicated script than just two lines of bash. > > Also note that using this second method, you can't deploy more than one > unit at a time, unless you want multiple units on containers on the same > machine (which I think would be pretty odd). > > > > On Fri, Jan 13, 2017 at 3:48 AM Rick Harding <<a href="mailto:rick.harding@canonical.com">rick.harding@canonical.com</a> </div></div>> <mailto:<a href="mailto:rick.harding@canonical.com">rick.harding@canonical.com</a>>> wrote: > > 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 <<a href="mailto:john@arbash-meinel.com">john@arbash-meinel.com</a> > <mailto:<a href="mailto:john@arbash-meinel.com">john@arbash-meinel.com</a>>> 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 > <<a href="mailto:stuart.bishop@canonical.com">stuart.bishop@canonical.com</a> > <mailto:<a href="mailto:stuart.bishop@canonical.com">stuart.bishop@canonical.com</a>>> wrote: > > On 13 January 2017 at 02:20, Nate Finch > <<a href="mailto:nate.finch@canonical.com">nate.finch@canonical.com</a> <mailto:<a href="mailto:nate.finch@canonical.com">nate.finch@canonical.com</a>>> > 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 <<a href="mailto:stuart.bishop@canonical.com">stuart.bishop@canonical.com</a> > <mailto:<a href="mailto:stuart.bishop@canonical.com">stuart.bishop@canonical.com</a>>> > > -- > Juju-dev mailing list > <a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a> <mailto:<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a>> > Modify settings or unsubscribe at: > <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a> > > > -- > Juju-dev mailing list > <a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a> <mailto:<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a>> > Modify settings or unsubscribe at: > <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a> > > -- > Juju-dev mailing list > <a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a> <mailto:<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a>> <div class="HOEnZb"><div class="h5">> Modify settings or unsubscribe at: > <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a> > > > </div></div> -- Juju-dev mailing list <a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a> </blockquote></div> <div> </div>-- <div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr">Reed O'Brien <div><div>✉ <a href="mailto:reed.obrien@canonical.com" target="_blank">reed.obrien@canonical.com</a></div><div style="font-size:12.8px">✆ 415-562-6797</div></div><div style="font-size:12.8px">💻 redir</div></div></div></div></div></div> </div>