+1
On Mon, Jan 16, 2017 at 9:28 AM, Aaron Bentley
wrote:
> 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
>process
+1
2017-01-16 18:28 GMT+01:00 Aaron Bentley :
> 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 i
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 constrain
So I think it is a fair point that if you did:
juju deploy application --constraits mem=4GB
and then did something like:
juju add-unit application --to lxd:XXX
That those constraints would end up interpreted differently. And also that:
juju add-unit application --to YYY
would similarly just
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
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-matc
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'
On 13 January 2017 at 02:20, Nate Finch 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
On Thu, Jan 12, 2017 at 12:40 PM, Nate Finch
wrote:
> The problem with trying to figure out how much "unused" RAM a host has is
> that it gets thrown out the window if you ever deploy any unit to the host
> machine, or if you deploy a unit in a container without a RAM constraint.
> Those units ma
>
>
> 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
Merlijn:
I definitely agree that having the same term mean different things on
different platforms is a really bad idea. I don't think we can change the
concept of constraints as minimums at this point, but maybe a new concept
of limits (to match lxd terminology) could be added. Limits really onl
On Thu, Jan 12, 2017 at 11:20 AM, Nate Finch
wrote:
> 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,
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
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.
14 matches
Mail list logo