On Fri, Sep 2, 2016 at 3:26 AM Marco Ceppi
wrote:
> On Thu, Sep 1, 2016 at 3:10 PM Nicholas Skaggs <
> nicholas.ska...@canonical.com> wrote:
>
>> A new development release of Juju, 2.0-beta17, is here!
>>
>> ## What's new?
>>
>> * add-model now takes region name as an optional positional argument
On Thu, Sep 1, 2016 at 3:10 PM Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:
> A new development release of Juju, 2.0-beta17, is here!
>
> ## What's new?
>
> * add-model now takes region name as an optional positional argument,
>to be consistent with bootstrap. The --region flag has
A new development release of Juju, 2.0-beta17, is here!
## What's new?
* add-model now takes region name as an optional positional argument,
to be consistent with bootstrap. The --region flag has been removed.
* show-controller now includes the agent version
* show-controllers has been removed
On 01/09/16 10:17, John Meinel wrote:
>
> 1.25 does not support LXD managed containers as it uses the old
> lxc-foo CLI to manage containers (lxc-start is not the same as "lxc
> start").
> juju-2.0 will use LXD managed containers but there are no plans to
> backport that support to 1.25
>
To be cl
I get the desire to remove friction everywhere we can, but unless
destroying controllers is a regular activity, I actually think SOME
friction is valuable here.
If controllers are constantly getting into a wedged state where they must
be killed, that's likely a product of a fast moving set of beta
If you have models it just doesn't work. so it's actually more "life
support" than slow death
On 1 Sep 2016 15:05, "Marco Ceppi" wrote:
> On Thu, Sep 1, 2016 at 9:59 AM Mark Ramm-Christensen (Canonical.com) <
> mark.ramm-christen...@canonical.com> wrote:
>
>> I believe keeping the --destroy-all-
1.25 does not support LXD managed containers as it uses the old lxc-foo CLI
to manage containers (lxc-start is not the same as "lxc start").
juju-2.0 will use LXD managed containers but there are no plans to backport
that support to 1.25
John
=:->
On Sep 1, 2016 4:12 PM, "Daniel Bidwell" wrote:
Hi Daniel
The transition from "1.0 everything" to "2.0 everything" is significant.
1.x Juju, 1.x MAAS and 1.x LXC all line up pretty well, as do 2.x MAAS,
2.x LXC/D, and 2.x Juju.
Crossing wires between those is not very easy at the moment - we do
intend to provide upgrade mechanisms but are focu
On 1 September 2016 at 14:59, Mark Ramm-Christensen (Canonical.com) <
mark.ramm-christen...@canonical.com> wrote:
> I believe keeping the --destroy-all-models flag is helpful in keeping you
> from accidentally destroying a controller that is hosting important models
> for someone without thinking.
On Thu, Sep 1, 2016 at 9:59 AM Mark Ramm-Christensen (Canonical.com) <
mark.ramm-christen...@canonical.com> wrote:
> I believe keeping the --destroy-all-models flag is helpful in keeping you
> from accidentally destroying a controller that is hosting important models
> for someone without thinking
I believe keeping the --destroy-all-models flag is helpful in keeping you
from accidentally destroying a controller that is hosting important models
for someone without thinking.
On Thu, Sep 1, 2016 at 3:40 PM, Marco Ceppi
wrote:
> Hey everyone,
>
> I know we've had discussions about this over t
Hey everyone,
I know we've had discussions about this over the past few months, but it
seems we have three commands that overlap pretty aggressively.
Using Juju beta16, and trying to 'destroy' a controller it looks like this
now:
```
root@ubuntu:~# juju help destroy-controller
Usage: juju destro
I have juju-1.25.6 on xenial and am trying to configure it to use the
local lxc containers. I have lxd configured to use a zfs volume for
containers. My .juju/environment.yaml looks like:
local:
type: local
lxc-clone: true
root-dir: /envision/lxc
network-bri
On 30 August 2016 at 23:02, Pete Vander Giessen <
pete.vandergies...@canonical.com> wrote:
The problems with the harness: patching sys.modules leads to a catch-22: if
> we don't leave the mocks in place, we still get import errors when using
> the mock library's mock.patch method, but if we do lea
Hello!
When using juju 2.0 on maas 1.9 or 2.0, you should get lxd containers
provisioned with as many interfaces as their host machine has, because
we're creating bridges on all configured host interfaces at initial boot
(e.g. eth0 becomes br-eth0, ens4.250 - br-ens4.250 and so on). Nothing
needs
Thanks Christian, boot strap completed with below work around.
Rajith
IBM AIX Certified, OCPCertified
Cell- 9901966577
Email: rajith...@in.ibm.com
From: Christian Muirhead
To: Rajith P Venkata/India/IBM@IBMIN
Cc: juju@lists.ubuntu.com, Katheri
Hi Rajith -
You need to run that command on the machine that will host your containers
(it doesn't need to be run as root). It configures LXD to listen to HTTPS
traffic on port 8443, so that the connection to LXD from the bootstrapped
controller (inside the container) will succeed. If you run that
Hi Christain,
In bug 1618636, you have mentioned of workaround
The workaround is to run this command to make lxd listen to https:
lxc config set core.https_address [::]
please give more details, so I can try with workaround
Thanks and Regard
Rajith
From: Christian Muirhead
To: Ra
18 matches
Mail list logo
