Rick Harding rick.harding at canonical.com
Mon Jun 5 20:10:04 UTC 2017

It always comes back to Juju being a tool pushing for best practice for
operations. It's hard for a hosted service to make any service promises
when things are running on personal laptops and such. It's all do-able, but
there's some form of what is the best practice thing to do. The controller
affinity is something akin to that. Controllers can be dealing with a lot
of communication at scale.

What's interesting here is exploring some idea of the development story
with Juju. I do find it interesting that you've got a sort of pre-seed
workspace you can create and setup.

On Mon, Jun 5, 2017 at 4:03 PM James Beedy <jamesbeedy at gmail.com> wrote:

> 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
> --
> 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/20170605/c5cef9b3/attachment.html>

More information about the Juju mailing list