The communication is from the agent to controller only from my
understanding. This is what allows a user to provision juju deployed
infrastructure behind any nat gateway, and for lxd deploys to work on
providers without juju networking support for containers (where the
containers get the lxdbr0
I think the primary advantage being less clutter to the end user. The
difference between the end user have to bootstrap and control things from
inside the vm vs from their host. For some reason this small change made some
of my users who were previously not really catching on, far more apt to
On 02/06/17 18:07, Anastasia Macmood wrote:
> On 02/06/17 15:11, Tim Penhey wrote:
...
>> Once we have confirmation from Solutions QA and JAAS that they are happy
>> with the release candidate, we will release is as 2.0.0
> 2.2.0 maybe?
Yes. That is what I meant.
Thanks,
Tim
--
Juju-dev
Interesting. I wouldn't have thought to use a manually added machine to use
JAAS to deploy applications to your local virtualbox. Is there a reason
this is easier than just "juju bootstrap lxd" from inside the VM?
I suppose our default lxd provider puts the new containers on a NAT bridge,
though
On 02/06/17 15:11, Tim Penhey wrote:
> Hi all,
>
> Sorry for the weird encrypted one.
>
> The date for the release candidate is Tuesday the 6th of June. We really
> wanted to get it out this week, but we hit two issues that we just had
> to get done before the release candidate. We decided that
