Re: OS X VMS on JAAS

2017-06-03 Thread Andrew Wilkins 
On Sat, Jun 3, 2017 at 2:56 PM John Meinel  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:

it goes something like this:

1. client connects to  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  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  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  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 
>>> wrote:
>>>

 https://medium.com/@jamesbeedy/using-jaas-to-deploy-lxd-containers-to-virtualbox-vms-on-os-x-a06a8046756a

 --
 Juju-dev mailing list
 juju-...@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev


>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>>
>>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
>

Re: OS X VMS on JAAS

2017-06-03 Thread Andrew Wilkins 
On Sat, Jun 3, 2017 at 2:56 PM John Meinel  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:

it goes something like this:

1. client connects to  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  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  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  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 
>>> 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:
>

Re: OS X VMS on JAAS

2017-06-03 Thread John Meinel 
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 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  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  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  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  wrote:
>>
>>> https://medium.com/@jamesbeedy/using-jaas-to-deploy-lxd-cont
>>> ainers-to-virtualbox-vms-on-os-x-a06a8046756a
>>>
>>> --
>>> Juju-dev mailing list
>>> juju-...@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju-dev
>>>
>>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: OS X VMS on JAAS

2017-06-03 Thread John Meinel 
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 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  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  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  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  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@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju-dev
>>>
>>>
>>
>> --
>> Juju mailing list
>> j...@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev