local provider

[Nate Finch]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20141212/cd057fb5/attachment.html>