...
> >> 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. John =:->
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
