@john, @andrew thanks for the details here On Sat, Jun 3, 2017 at 10:21 PM, Andrew Wilkins < andrew.wilk...@canonical.com> wrote:
> On Sat, Jun 3, 2017 at 2:56 PM John Meinel <j...@arbash-meinel.com> wrote: > >> 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. >> > > Given the command: > > $ juju add-machine ssh:<target> > > it goes something like this: > > 1. client connects to <target> via SSH, and performs basic hardware/OS > discovery > 2. client asks controller to add a machine entry, and controller returns a > script to be executed on the target machine, using the discovered details, > in order to fetch and install jujud > 3. client executes that script over the SSH connection > > Once initial setup is complete, then it is definitely true that all >> connections are initiated from the agent running on the controlled machine >> to the controller. The controller no longer tries to socket.connect to the >> machine. (In 1.X 'actions' were initiated via ssh from the controller, but >> in 2.X the agents listen to see if there are any actions to run like they >> do for all other changes.) >> >> Now, given that he added a model into "us-east-1" if he ever did just a >> plain "juju add-machine" or "juju deploy" (without --to) it would >> definitely create a new instance in AWS and start configuring it, rather >> than from your VM. >> >> Which is why using something like the "lxd provider" would be a more >> natural use case, but according to James the sticking point is having to >> set up a controller in the first place. So "--to lxd:0" is easier for them >> to think about than setting up a provider and letting it decide how to >> allocate machines. >> >> Note, it probably wouldn't be possible to use JAAS to drive an LXD >> provider, because *that* would have JAAS be trying to make a direct >> connection to your LXD agent in order to provision the next machine. >> However "--to lxd:0" has the local juju agent (running for 'machine 0') >> talking to the local LXD agent in order to create a container. >> >> John >> =:-> >> >> >> On Fri, Jun 2, 2017 at 6:28 PM, Jay Wren <jay.w...@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 <jamesbe...@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 <j...@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 <jamesbe...@gmail.com> >>>> wrote: >>>> >>>>> https://medium.com/@jamesbeedy/using-jaas-to-deploy-lxd-containers-to- >>>>> virtualbox-vms-on-os-x-a06a8046756a >>>>> >>>>> -- >>>>> Juju-dev mailing list >>>>> Juju-dev@lists.ubuntu.com >>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/ >>>>> mailman/listinfo/juju-dev >>>>> >>>>> >>>> >>>> -- >>>> Juju mailing list >>>> j...@lists.ubuntu.com >>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/ >>>> mailman/listinfo/juju >>>> >>>> >>> >> -- >> Juju-dev mailing list >> Juju-dev@lists.ubuntu.com >> Modify settings or unsubscribe at: https://lists.ubuntu.com/ >> mailman/listinfo/juju-dev >> >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
