<div dir="ltr">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. <div><br></div><div>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. </div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 5, 2017 at 4:03 PM James Beedy <<a href="mailto:jamesbeedy@gmail.com">jamesbeedy@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This raises the question: why do we need a provider -> controller affinity at all?</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 5, 2017 at 12:23 PM, Nicholas Skaggs <span dir="ltr"><<a href="mailto:nicholas.skaggs@canonical.com" target="_blank">nicholas.skaggs@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 06/03/2017 02:56 AM, John Meinel wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
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.)<br>
<br>
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.<br>
</blockquote></span>
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.<span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
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.<br>
</blockquote></span>
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.<span class="m_6271995946259673685HOEnZb"><font color="#888888"><br>
<br>
Nicholas<br>
</font></span></blockquote></div><br></div>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com" target="_blank">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</blockquote></div>