On 18 December 2014 at 21:16, Kapil Thangavelu <[email protected]> wrote:
>> > 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. >> >> Do you mean local-provider would be less devel/demo if the >> state-server was place in a container (machine-0) instead of co-opting >> localhost to be machine-0? > > nutshell yes that's one major improvement. but there's a long list of > improvements to the local provider to make it less flakey and given its > often developers first introduction to juju i don't think we should be > treating it as a second class citizen. it sounds like marco is going to try > and paper over some of them with a plugin, but i think we should be looking > at a fresh start based on lxd. I wouldn't so much call the local provider the first impression, but the main impression. Most of the time spent with juju will be developing charms, because the whole point is to minimize the effort needed to operate the production systems. Developing charms is primarily done with the local provider, because not all of us have or want an OpenStack cluster under our desks (and the local provider seems to be faster at provisioning and tearing down VMs). From my POV, the local provider describes how Juju is supposed to work. -- Stuart Bishop <[email protected]> -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
