Re: A new development release of Juju, 2.1-beta4, is here!

[Mark Shuttleworth]

As we push to Juju 2.1 there are a couple of items that would be really
good to get testing feedback on!

On 06/01/17 15:06, Nicholas Skaggs wrote:
> Model Migration is no longer behind a feature flag

'Model migration' is key to ongoing easy and automatic upgrades on the
server. By migrating the model from a 2.n to 2.n+1 controller you will
have a very safe upgrade with rollback if safety tests don't pass. We'd
really like to help the Juju operator community move forward with Juju
releases more quickly, since there are loads of performance and
operations improvements landing at the moment, so please test model
migration. For fun, you should be able to move the same model from one
controller to another and back very reliably.

> vSphere provider improvements

Many folks have easier access to vSphere than public or private cloud
infrastructure, so we'd like to hear how you find the add-cloud and
bootstrap experiences, and how big bundles like kubernetes and hadoop
perform for you there.

Try 'juju add-cloud' and see how it goes!

> [conjure-up] New ‘Architecture’ button allows editing machine
> placement, including specifying a machine in a MAAS

Conjure-up is proving to be a superb front-end to Juju for initial
deployments of complex stuff like OpenStack. Please do try it, possibly
with Kubernetes or OpenStack. A 'spell' is a bundle with a few bells on
it, so if you have bundles that would benefit from conjuring up then
please shout if you need a hand crafting them.

Mark


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: lxd and constraints

[Reed O'Brien]

+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
>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.
>
> 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  > > 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  > > 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:
> 

Re: lxd and constraints

[Merlijn Sebrechts]

+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 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.
>
> 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  > > 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  > > 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:
> >  j

Re: lxd and constraints

[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 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.

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  > 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  > 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 val