juju vs. Puppet/Chef/Salt/Ansible/etc.

[Eric Snow]

Thanks for the feedback, Kapil.

On Tue, Dec 9, 2014 at 5:03 AM, Kapil Thangavelu
<kapil.thangavelu at canonical.com> wrote:
> On Mon, Dec 8, 2014 at 6:35 PM, Eric Snow <eric.snow at canonical.com> wrote:
>> The reaction I get most often from folks that aren't familiar with
>> juju and skim through the juju site is that it looks like a competitor
>> to the various configuration management tools out there like Puppet or
>> Salt.  However, my experience is that while they have some overlap,
>> they sit at different layers.
>
> Agreed. I think the messaging on the sites messaging could use some work,

How do we go about doing something about this?

>> Have I grown out of touch?  Conceivably those projects have or are
>> working on juju-like functionality that I'm not aware of.
>
> They aren't, there's a whole new set of tools though that are working on
> orchestration features,  though it may be a rather ambiguous term yet, they
> still advertise themselves as such. the growth of containers/docker has
> reinforced the value of orchesrtation tools since  image delivery obviates
> most config management, ie. having a bunch of containers that don't talk to
> each across nodes other is obviously a problem in want of a a solution
> (discovery, connectivity, topology composition) aka orchestration.

Very interesting.

>> If not (or
>> even if so), what's the best way to educate people on what juju is and
>> how it will help them when they're already steeped in the lower-layer
>> config. management world?
>
> Explain orchestration as a higher level construct which focuses on services
> management via iaas provisioning, service discovery, service automation (db
> creation, etc) in a reusable way.  Coupled with an ecosystem of service
> definitions that offers user composed multi-node solutions.
>
> Try showing them a deployer config/bundle  and ask them to compare to the
> comparable lower level tool config.

I had tried the explanation route to no avail.  I'll probably work up
a demo for the specific folks I have in mind.  I think juju is one of
those things that makes more sense when you see it in action.

One thought I had is that we could work up a demo-in-a-box.  Either
make a VM image available (with local provider in it?) or fix local
provider so that it runs entirely in VMs/containers.  For the latter
we could distribute a script that spins up the new local provider to
make it super easy for someone to try juju out locally, AKA
juju-in-a-box.

>> Related to that, how can we help those same folks wrap all their
>> existing recipes, etc. in charms?  It's got to be easy enough that
>> they can justify the effort.
>
> michael's reply goes through the most cm tool used in charms, ansible. we've
> got production and example charms written with several different tools.
> nutshell using cm tools in solo single host  with facts/vars fed in via
> config, and relations, and executed in place of hooks.

Awesome.  It seems to me that we could advertise this better.

-eric