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.ska...@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@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
