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 <jamesbe...@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.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-...@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
