On Fri, Dec 12, 2014 at 11:26 AM, Nate Finch <nate.fi...@canonical.com> wrote:
> 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? > no, that's a bad idea, imo. first as you say its people first experience with juju and the way its deployment usage fits very well with some folks production needs ( ie. i have a big machine in the corner and juju can deploy workloads on it). I think the issue primarily is that of implementation, and the mindset among developers/implementers that we don't support it. Most of the reasons why its different on an implementation level disappear with lxd, at which point we should support it for dev and prod. -k
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
