Switch from Puppet to Chef or Ansible?

[seanknox]

Probably the biggest source of confusion for people working with Boxen is Puppet. Puppet is complicated, has its own DSL, is extremely verbose, and as an external dependency is a big pain to work with—here's one example of probably many where it took over 2 months to fix Puppet using curl insecurely over SSL. Debugging Puppet errors is extremely tedious.

While Boxen makes an developer user's life much easier, life for a Boxen maintainer (for an org or otherwise) is difficult.

Goals

I'd like a framework that is:

• Easy to configure
• Easy to maintain
• Easy to extend
• Fast/efficient
• Used by a large community

To those ends, what does the Boxen community think of switching from Puppet as its idempotent runner to Chef or Ansible?

Chef

Pros:

• It's Ruby. Its DSL is Ruby'esqe. If you know Ruby—which most of Boxen is written in—you can work with Chef.
• Thus, creating custom Chef providers is easier.
• Chef's "data-bags" can be used in place of Puppet's Hiera (I believe)
• Can be used with OS X's system Ruby (I think?)

Cons:

• ?

Ansible

Pros:

• Very simple to setup and get running
• Ansible is written Python, however modules can be in any language
• YAML files for everything

Cons:

• pip needs to be installed first on the system (although I suppose not a big deal, since bundler is for Boxen)

I'm surely missing lots. Obviously there would also be the tremendous work of rewriting Boxen modules for the new framework. Would love to hear folks thoughts. cc: @boxen/owners

[rafaelfranca]

Not sure if we will have any gain changing from puppet for something else. It is seems like we saying "ok, people don't understand our open source library because it is written in C. Lets rewrite it in Ruby".

Of course syntax matters, but I don't see it as a problem. If people want to use Boxen they can just learn Puppet.

I never used Chef or Ansible before, so I can't say if they provide everything we want, but even if they provide, is puppet so bad that it is worth to rewrite everything?

[seanknox]

Having now deployed Boxen for developer on-boarding at three companies, everyone appreciates it but hates working in it, and the main reason for that is Puppet's DSL and how difficult it is to debug and troubleshoot typos or syntax errors in manifests. Here's one example from an actual project:

  ## rbenv-installed gems cannot be run in the boxen installation environment
  ## which uses the system ruby. The environment must be cleared (env -i)
  ## so an installed ruby (and gems) can be used in a new shell.
  ## env -i also clears out SHELL, so it must be defined when running commands.

  $base_environment = "env -i SHELL=/bin/bash /bin/bash -c 'source /opt/boxen/env.sh &&"
  $bundle = "$base_environment RBENV_VERSION=${project_ruby_version} bundle"

  ## NOTE: don't forget the trailing single quote in the command!
  ## e.g.
  ## command => "${bundle} install'"

  ## bundle install
  exec { 'bundle install project':
    provider  => 'shell',
    command   => "${bundle} install'",
    cwd       => "${boxen::config::srcdir}/project-repo",
    require   => [
      Ruby[$project_ruby_version],
      Ruby_Gem["bundler for all rubies"],
      Service['mysql']
    ],
    unless    => "${bundle} check'",
    timeout   => 1800
  }

Look at the command line. The cost of DRY'ing up that long bundle command is: don't forget that last single quote every time you use that $bundle alias, or it all breaks!

This isn't a question of using a different language, it's how easy to use and maintainable is a framework for its users.

[rafaelfranca]

everyone appreciates it but hates working in it

Is it a problem of the tool or an education problem? If we where using Ansible or change this would be different? I don't think so. People has personal preferences and it is fine, but I don't think personal preferences should drive a huge change like this one.

Also, for a open source project like this one we should think in "what are the tools the maintainers are comfortable with?". I believe this change would not just require a lot of hours to rewrite as a lot of hours for the maintainers learn how to use the new tool properly.

And still the benefits are too obscure to justify a decision like this one. Everything we have now is: some people don't like Puppet, and maybe if we change to something else they will like.

[seanknox]

Again, three different companies. All of them software companies, senior engineers fluent in multiple programming languages, people with significant ops experience, some ex-Pivotal Labs people. Puppet, through Boxen, is complex. This isn't an education problem.

Puppet was chosen for Boxen because that's what GitHub's devops people use(d) to maintain their corporate infrastructure. And used to manage large enterprise, Puppet can be fine—large enterprises are complex to manage. On a single developers machine, Puppet is burdensome, obtuse, and again, difficult to debug. Now that most/all of the GH devops folks have moved on from GitHub or this project, the project constraints have changed. We're no longer forced to use it and can choose something better.

[rafaelfranca]

Do we have how to assert that any other choice would be better?

Not saying that we can't, just saying that is too much work for a (dubious?) gain.

[seanknox]

I suppose a spike with basic functionality and some module examples would be in order. Initially, I want to get feedback from folks with more experience using these systems.

[rafaelfranca]

Well, I can't say no if we can assert that it will be worth, and more important I can't say no if you want to try. But I can't put too much energy on this right now, sorry. I'll definitely review and give inputs though.

[takashiyoshida]

@seanknox Have you tried alternatives to Boxen? Battleschool might fit your bill if you do not want to use Puppet. I don't have a first hand experience with it but you may want to have a look. You can also read Spencer Gibb's blog too.

[MikeMcQuaid]

Now that most/all of the GH devops folks have moved on from GitHub or this project, the project constraints have changed. We're no longer forced to use it and can choose something better.

Given my personal experiences with Chef I'm not convinced it would be any easier (and it would probably be worse). Puppet has a Ruby DSL so it's maybe worth investigating if that can be used.

For what it's worth I personally agree that Puppet is extremely painful to work with for something like Boxen but to rewrite it in e.g. Chef would require reimplementing essentially the whole project from scratch, all submodules and introducing huge numbers of new bugs. For this reason: it won't happen and if it does it won't really be Boxen any more.

If you want something lighter-weight I'd personally recommend using a combination of Homebrew, Homebrew Cask, Homebrew Bundle and a shell script to do basic system setup (e.g. installing the above, turning on full-disk encryption etc.).