Juju and Chef

Chef Infra (archive)
1

I don’t understand how Juju is used alongside with Chef…
Any experience? Differences between the two approaches? Chef is
configuration management and Juju is orchestration, but yeah, I am looking
forward to reading explanations in English. I’ve googled and read many
posts/papers and none really explained the difference.

Thanks!

Cheers,
Yeukhon

2

Think of it in terms of using a shell script to launch a perl script.

Do in each what makes sense in each.

On Thu, Dec 13, 2012 at 1:45 PM, John Wong gokoproject@gmail.com wrote:

I don't understand how Juju is used alongside with Chef....
Any experience? Differences between the two approaches? Chef is
configuration management and Juju is orchestration, but yeah, I am looking
forward to reading explanations in English. I've googled and read many
posts/papers and none really explained the difference.

Thanks!

Cheers,
Yeukhon

--

3

Orchestration has come up at the Chef design summit both years and it's a
fairly overloaded term so I can understand your desire for something
more succinct. When building a service that is distributed over many nodes
certain challenges manifest like dependencies and ordering not of recipes
on a single node, but where you need node A to converge with recipe B
before node C can converge with recipe D. You can do this in Chef, it is
simply more elegant in Juju because of it's tight integration with a
distributed lock manager (zookeeper) [1]. There's several different ways
that people handle it in chef w/o a distributed lock manager:

  1. Skipping parts of a recipe, expecting node attributes or databags to be
    manipulated by a recipe(s) on other nodes to achieve a state requirement in
    a future convergence
  2. Failing a recipe, expecting node attributes or databags to be
    manipulated by a recipe(s) on other nodes to achieve a state requirement in
    a future convergence
  3. Polling with timeout in a recipe, expecting node attributes or databags
    to be manipulated by a recipe(s) on other nodes to achieve a state
    requirement during the current convergence window

That said, chef combined with a distributed lock manager allows for more
elegant solutions involving the "watch" primitive. I've been seriously
tinkering with the idea of setting up zookeeper, placing metadata that
could benefit from a watch in znodes and having a ZK [3] daemon that
responds to watches by signaling the chef-client deamon or runs chef-solo.

I'm by no means a Juju expert so perhaps this is something that could
easily be done by utilizing Juju alongside Chef. I wouldn't feel
comfortable doing this though because Juju is clearly more than a just lock
manager and I'm not a fan of using two tools with overlapping domain to add
a single primitive than can be satisfied with a simpler tool.

Doozer is another lock manager that appears to be able to satisfy watches,
it and Zookeeper are influenced by the paper Google published on their
Chubby lock service [4]

[1] Charmhub | The Open Operator Collection
[2] http://zookeeper.apache.org/
[3] GitHub - zk-ruby/zk: A High-Level wrapper for Apache's Zookeeper
[4] The Chubby lock service for loosely-coupled distributed systems

--

Kyle