John Meinel john at arbash-meinel.com
Tue Jun 6 03:53:36 UTC 2017


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

Its essentially the 'manual provider', which is explicitly about you have
to tell Juju about the machines you might want to use.  I wouldn't think it
would be hard to create a model that used manual provisioning, but its
probably not something we've been driving as a great use case. Things like
needing the right routing, etc, mean its easy for people to add machines
that won't actually work, so it isn't something we've pushed.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170606/989d364a/attachment.html>

More information about the Juju mailing list