James Beedy jamesbeedy at gmail.com
Fri Jun 2 15:00:23 UTC 2017

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). Here is a good example of both scenarios in
one model http://paste.ubuntu.com/24749128/

On Fri, Jun 2, 2017 at 7:28 AM, Jay Wren <jay.wren at canonical.com> wrote:

> I do not understand how this works. Could someone with knowledge of how
> jujud on a  controller communicates with jujud agents on units describe how
> that is done?
> My limited understanding must be wrong give that James has this working.
> This is what I thought:
> On most cloud providers: add-machine instructs the cloud provider to start
> a new instance and the cloud-config passed to cloud-init includes how to
> download jujud agent and run it and configure it with public key trust of
> the juju controller.
> On manually added machine: same thing only instead of cloud-init and
> cloud-config an ssh connection is used to perform the same commands.
> I had thought the juju controller was initiating the ssh-connection to the
> address given in the add-machine command and that a non-internet routable
> address would simply not work as the controller cannot open any TCP
> connection to it. This is where my understanding stops.
> Please, anyone, describe how this works?
> --
> Jay
> On Fri, Jun 2, 2017 at 9:42 AM, James Beedy <jamesbeedy at gmail.com> wrote:
>> 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 jump in. I personally like it because these little vms go further when
>> they don't have the controller on them as well. @jameinel totally, possibly
>> I'll add the bridge bits in place of the lxd-proxy in that write up, or
>> possibly in another.
>> ~James
>> On Jun 2, 2017, at 12:56 AM, John Meinel <john at arbash-meinel.com> wrote:
>> 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 you can reconfigure 'lxdbr0' to bridge your 'eth0' as well.
>> John
>> =:->
>> On Fri, Jun 2, 2017 at 8:33 AM, James Beedy <jamesbeedy at gmail.com> wrote:
>>> https://medium.com/@jamesbeedy/using-jaas-to-deploy-lxd-cont
>>> ainers-to-virtualbox-vms-on-os-x-a06a8046756a
>>> --
>>> Juju-dev mailing list
>>> Juju-dev at lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju-dev
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170602/da1c4dc8/attachment.html>

More information about the Juju mailing list