You can add a manually provisioned machine to any model, as long as there
is connectivity from the machine to the controller. Now, I would have
thought initial setup was initiated by the Controller, but its possible
that initial setup is actually initiated from the client.
Once initial setup is co
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 nat
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 ju
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 mailing
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 y
