Ubuntu – How to make a Juju Charm’s revision match the Bazaar revision of its repo

You can use the -u option to juju deploy to speed iteration during development of your charms:

  -u, --upgrade         Deploy the charm on disk, increments revision if
                        needed

e.g.,

juju deploy -u charm-name

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.

Opinions

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.