OS X VMS on JAAS

[James Beedy]

This raises the question: why do we need a provider -> controller affinity
at all?

On Mon, Jun 5, 2017 at 12:23 PM, Nicholas Skaggs <
nicholas.skaggs at canonical.com> wrote:

> On 06/03/2017 02:56 AM, 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.
>>
>> 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.
>>
> Is it possible for us to convey the model's proper location, even when
> using jaas? He's in effect lying to the controller which does have the
> knock-on affect of weird behavior.
>
>>
>> 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.
>>
> If this is a useful case, could we define it as a mode of operation and
> have juju just work in such a scenario? It's an interesting mix of allowing
> the benefits of jaas for manually provisioned machines and environments.
> Just eliminating the weird behaviors and having to pretend it's a known
> cloud / provider could be useful. An assume nothing mode if you will.
>
> Nicholas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20170605/1266e905/attachment-0001.html>