Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

Have tried asking 3rd party about key differences between Juju and Puppet/Chef. 3rd parties are not too familiar with Juju and could not say. They simply stated the others have a lot of momentum, and it would be hard to overcome their lead.

Would those closest to Juju be willing to highlight the advantages of this software, and why it will overtake Puppet/Chef in the config management arena?

share|improve this question
add comment

2 Answers

Mark, this is a great question, and was the first one I asked when somebody told me about Juju. Here's some of the big differences.

  • Juju encapsulates services - a charm defines all the ways the service needs to expose or consume config data to/from other services. How a charm does that is the charm's business. It can use any tool from shell scripts to Chef in solo mode, to do that.

  • Juju orchestrates provisioning - juju keeps track of the resources it has available to it, and can add or remove them as needed. Currently these resources are only EC2 machines (which means Eucalyptus and OpenStack should work too) Other resources, like local LXC containers (for development) and Ubuntu Orchestra managed machines are in the works. Eventually storage orchestration (ala, EBS volume management) will be possible too.

  • Juju makes sharing easy - Right now sharing is done via bzr branches on launchpad. However, the plan is to have Juju Charms in a distribution that is well integrated.

I hope that helps!

share|improve this answer
1  
Puppet deals with describing resources, provisioning VMs, and sharing modules too. Can you explain how Juju does it differently or better, or solves a different problem? –  poolie Apr 17 '13 at 23:58
    
Was not aware of puppet cloud provisioner at the time of that answer. Puppet modules were not name spaced the last time I checked, and thus present sharing problems that may require a user to modify the code of a puppet module to make use of it. –  SpamapS May 1 '13 at 7:41
    
There are namespaces in puppet. I haven't used Puppet much, but my understanding is that problems mostly occur when two modules are actually trying to manage the same logical thing. Does Juju have some systematic way to prevent that? –  poolie May 2 '13 at 1:09
    
The namespaces in puppet have undergone recent changes to make it easier to share a working stand-alone puppet module. In the past one needed the equivalent of global variables to communicate between two modules. Juju doesn't deal in any way shape or form with configuration of the instance, it is just a facilitator for orchestration, so no, it will not prevent two charms battling over a single file. –  SpamapS May 3 '13 at 7:49
1  
Hi @SpamapS , This is regarding your second point (aka Juju orchestrates provisioning). In puppet we can define relationships using "require", "notify" etc. Can't we simply use this constructs to orchestration provisioning? Or Juju provides a different level of orchestration semantics? –  Denis Weerasiri May 21 '13 at 0:36
show 1 more comment

(Disclaimer - I'm the founder of Puppet and CEO of Puppet Labs)

I don't know juju terribly well, but from what I can tell, they somewhat sit at different layers. Puppet is great at managing the behaviors and capabilities of machines themselves, whereas juju seems primarily dedicated to talking about sets of machines and largely punts how to make the machines behave any specific way to external tools like Puppet or shell scripts.

Our strategy with Puppet is to build the best stack from the ground up, whereas juju appears to be a specific layer of the stack and leaving other layers to other tools. Thus, while you can solve the whole problem with Puppet (albeit sometimes with a bit more work than you might like), you'll need to integrate juju with other tools to get much done.

Really, juju seems like an on-premise version of CloudFormation from Amazon, albeit without the graph and such. So, usable with Puppet etc., but not a replacement for it.

share|improve this answer
2  
Not sure if punting is the right word here.. thats like saying packages punt building the software to autotools/scons/setup.py. If packages tried to do every step of every build, we'd have no packages! –  SpamapS Oct 17 '11 at 15:27
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.