It seems like a lot of people get confused by Juju, because it is different than the tools they know. They want to deploy stuff with Juju, and so they get a machine from AWS/Digital Ocean/whatever, ssh into the machine, install juju, and run the local provider.... and then wonder why they can't access their services from outside the machine.
I think this stems from two things - one is the people are used to chef/puppet/etc where you ssh into the machine and then run the install there (note: I know nothing about these tools, so may be mis-characterizing them). Whereas with Juju, you are perfectly able to orchestrate an install on a remote machine in the cloud from your laptop. The other is the local provider. The intent of the local provider is to give users a way to easily try out Juju without needing to spin up real machines in the cloud. It's also very useful for testing out charms during charm development and/or testing service deployments. It's not very useful for real production environments... but yet some people still try to shoehorn it into that job. I think one easy thing we could do to better indicate the purpose of the local provider is to simply rename it. If we named it the "demo" provider, it would be much more clear to users that it is not expected to be used for deploying a production environment. This could be as easy as aliasing "local" to "demo" and making the default environments.yaml print out with the local provider renamed to "demo". (feel free to s/demo/testing/ or any other "not ready for production" word) What do you think? -Nate
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
