OS X VMS on JAAS

James Beedy jamesbeedy at gmail.com
Sun Jun 4 15:31:28 UTC 2017


@john, @andrew thanks for the details here

On Sat, Jun 3, 2017 at 10:21 PM, Andrew Wilkins <
andrew.wilkins at canonical.com> wrote:

> On Sat, Jun 3, 2017 at 2:56 PM John Meinel <john at 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.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-containers-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/
>>>>> mailman/listinfo/juju-dev
>>>>>
>>>>>
>>>>
>>>> --
>>>> Juju mailing list
>>>> Juju at lists.ubuntu.com
>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>>>> mailman/listinfo/juju
>>>>
>>>>
>>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>> mailman/listinfo/juju-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170604/edb2eaf1/attachment.html>


More information about the Juju mailing list