Thanks for the feedback, Kapil. On Tue, Dec 9, 2014 at 5:03 AM, Kapil Thangavelu <[email protected]> wrote: > On Mon, Dec 8, 2014 at 6:35 PM, Eric Snow <[email protected]> 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 -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
