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:
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:
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.
Best Answer
Well, if this was a Juju config option for the charm, I think the charm should restart it automatically. If not, it probably should be added to the config (but the README says "This charm doesn't offer any configuration as Alice doesn't have any command line configuration tools, everything is done through the browser.")