It is clear from this post that Juju sits at a different layer than Chef Server. Juju sits at the orchestration or service layer, while Chef sits more at the individual server or configuration layer.

At one of Canonical's main Juju pages, it states that Juju is designed to "co-exist" with tools like Chef and Puppet, taking the process "one step further". I have scoured the internet for the past several weeks on this subject and cannot find a good explanation of how , though, a tool like Chef will co-exist with Juju.

So, to breakdown the overarching question in the title: (particular interest in Juju working together with a Chef Server)

  • What is an example of a charm "written in Chef"? Is it simply a charm written in bash that then calls the chef-solo command? If so, can a charm call the chef-client command to work in concert with a Chef Server?
  • Where is the overlap between Juju and Chef? For instance, the apache2 charm has its config-changed hook where it makes config changes that, in the Chef world, would take place in a recipe by applying a template file. If a Juju charm were to work along with a Chef cookbook on deploying an apache2 service (cluster) it would almost seem that an "apache2-chef" charm would have to be written so that you could separate out the tasks. In this case, the apache2 charm in the Charm Store would be less than helpful.
  • If you have Chef roles applied to nodes (service units) that are deployed/managed by Juju and your sysadmin decides to change the firewall rules for a particular server role and does this in the Chef role, is Juju going to ever overwrite those changes?
  • More simply, can Juju be a Chef Server wrapper, like Ironfan?

I view Chef Server as the how whereas Juju can do the how, but also brings what to the table. Meaning that the real current state of services and machines can be queried and acted upon. You can't do this in Chef Server. My goal is to bring Juju's awareness and service orchestration capability into a Chef Server-managed infrastructure.

It almost seems that a whole set of charms would have to be written where all Chef-managed tasks/config info are left out.

I would love to hear weigh-ins from someone at Canonical (like Jorge Castro) and from Opscode (like A. Jacob or J. Timberman).


awesome questions!

the tl;dr

I'd like to break your question(s) down over a couple of comments... first off, here're a couple of general approaches to integrating chef and juju:

  • charms hooks can use existing chef recipes that run solo-style on service units (recommended)

  • juju service units register with an existing chef-server using a chef-node subordinate service

These ideas haven't been implemented/tested yet for chef, but the puppet equivalents exist.

the... um.. not-so-short answer

Here's a little more of a breakdown of two approaches to integrating chef and juju:

Juju as top-dog

Here juju runs the show. The biggest value juju provides is event coordination during distributed configuration management... hence the "service orchestration" moniker. Juju charms consist of hooks which are called by juju at "the right time" when coordinating service management. The implementation of these hooks is pretty much open. They're shell scripts, source code, puppet manifests, or... chef recipes.

Juju breaks bits of any service config up into:

  • "installation".. the bits that're specific to installing a particular service onto a node

  • "relation".. the bits of config that're needed to relate that service to some other service

The key to using chef recipes as hook implementations is exactly this... you have to make sure that the recipes you're using respect this separation of concerns. Otherwise, there's nothing that prevents using off-the-shelf cookbooks. You can leverage existing recipes you've spent time/money to develop.... You just need to make sure you can call the relation-specific stuff separately from the installation-specific stuff.

We need some examples of this, but I think it'll be popular b/c chef has a great dsl, a great templating tool, and is much more pleasant to use than bash when writing complex config. For simple config, chef recipes are a little overkill imo, so this method of integration is pretty much the best of both worlds... and has serious legs going forward.

Chef as top-dog

The idea here is to integrate juju services into an existing chef-server managed infrastructure. To do this, you'd need to write a chef-node subordinate charm. This subordinate service would be attached to primary juju services and would effectively register these services as nodes (in particular roles) with the chef server. Subs can be attached during juju service startup, or anytime later throughout each service's lifecycle.

I'm thinking this'd be quite similar to the puppet-node sub. All necessary keys, roles, etc would be specified via config to the chef-node subordinate charm. I'd start there. A more sophisticated approach would be for the chef-node sub to interrogate both the primary service it's attached to and its chef-server to dynamically determine roles, but that'd be quite a bit harder than just specifying them in config for the sub.


I'd definitely recommend method 1 above, if possible. Having the coordination layer on top of the configuration tools will probably work well long-term. Needless to say, real-world infrastructures might be some combo or variation of both approaches for a period of time... especially during migration. Planned coexistance using method 2 would probably only work if the components managed by both tools were somewhat orthogonal to each other. Not sure exactly what that would look like. Perhaps juju and chef manage separate relatively decoupled services? I suspect it might work well to let juju manage primary services and have chef manage more infrastructure aspects. Dunno. That's a bit of a longer discussion though :)

Side note... you can also use juju to manage chef-server itself... even large complex multi-tier chef-server installations. I haven't looked at the chef-server charm lately, but if it doesn't currently handle tiering and separation of services, then it can certainly be made to.

I'd love to see more examples of both types of chef integration mentioned above... it's been on my wish / todo list for a while, but has yet to bubble up high enough in priority to get done... please help if you're interested!

ok, that's a decent chunk of rambling :)... let's start there, then we can go into more detail in subsequent comment blocks.

| improve this answer | |
  • great stuff here. "I suspect it might work well to let juju manage primary services and have chef manage more infrastructure aspects." This is what I'm really interested in, as we share this same suspicion. Like you said, Chef's DSL and templating are great for configuration. However, there are other aspects of Chef Server (data bags) that would be hard to let go of, in your first method. Juju, being at service level, should be top dog, but I feel it should allow Chef to do what it does best in the Chef Server model. Must work for both devs and admins. But perhaps no need for Chef Server. – Ian D. Rossi Mar 18 '13 at 14:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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