local provider

[Stuart Bishop]

On 18 December 2014 at 21:16, Kapil Thangavelu
<kapil.thangavelu at canonical.com> 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 <stuart.bishop at canonical.com>