iain / roundsman Goto Github PK

I'm not exactly sure what has change, it is probably an issue with one of minor-chef version, but I get a dependency-error for the chef-install with 0.10.8:

 * executing "sudo -p 'sudo password: ' gem install chef -v \"~> 0.10.8\" --quiet --no-ri --no-rdoc"
    servers: ["192.168.1.10"]
    [192.168.1.10] executing command
ERROR:  While executing gem ... (Gem::DependencyError)
    Unable to resolve dependencies: chef requires net-ssh (~> 2.2.2); net-ssh-multi requires net-ssh (>= 2.1.4); net-ssh-gateway requires net-ssh (>= 2.6.5)
    command finished in 23491ms
failed: "env RAILS_ENV=production GIT_SSL_NO_VERIFY=true sh -c 'sudo -p '\\''sudo password: '\\'' gem install chef -v \"~> 0.10.8\" --quiet --no-ri --no-rdoc'" on 192.168.1.10

If updated the chef-reference to use 11.4.0&the error is gone. Not sure how much else this breaks, but this seems to be working for now...

Methods from https://github.com/iain/roundsman/blob/master/lib/roundsman/capistrano.rb attempt to leave capistrano variables (
https://github.com/capistrano/capistrano/blob/master/lib/capistrano/configuration/variables.rb) unaffected but does not actually do this.

For example, after an execution of generate_attributes :releases variable defined at
https://github.com/capistrano/capistrano/blob/master/lib/capistrano/recipes/deploy.rb#L60 is evaluated and cached.

This happens because :releases variable is referenced from :current_releases and :previous_release.

This problem is important when combining chef:default and deploy:cold tasks in another task. deploy:cold updates releases but :releases variable value is already evaluated and cached.

If a server doesn't need the app deployed on it, it doesn't mean I don't want to run chef on it. How come all tasks in roundsman are tagged with except: { no_release: true}? That makes it impossible to bootstrap, say, a redis server, on which you don't want your app deployed.

Whenever I try to run roundsman.run_list or roundsman:configuration I get this message.

Support for (encrypted) databags would be very nice.
There are some forks out there, but I can't try them.

when I try to install the gems with

bundle install
rake install

I get the following error when running cap -T:

cannot load such file -- roundsman/capistrano (LoadError)

Whenever #runlist is called "apt-get update" is issued on the server. This slows down otherwise fast runlists. I'd suggest s/th like this: https://gist.github.com/4692247

Roundsman specifies chef version 0.10.8 while chef doesn't specify the moneta version at all: http://tickets.opscode.com/browse/CHEF-3721 Chef versions < 10.16.4 break with all moneta versions > 0.7.0. Either Roundsman should upgrade the chef version or follow chefs practice of not specing the version at all.

As workaround I've set the chef version in capistrano:

set :chef_version, '~> 10.18'

https://github.com/iain/roundsman/blob/master/lib/roundsman/capistrano.rb#L95

here

  if installed_version.include?(required_version)
    if fetch(:care_about_ruby_version)
      logger.info "Ruby #{installed_version} matches the required version: #{required_version}."
      return false
    else
      logger.info "Already installed Ruby #{installed_version}, not #{required_version}. Set :care_about_ruby_version if you want to fix this."
      return false
    end
  else
    logger.info "Ruby version mismatch. Installed version: #{installed_version}, required is #{required_version}"
    return true
  end

I had another version of ruby installed
no matter what I set to care_about_ruby_version, install_ruby? will always return true, and roundsman will always install ruby
I think it's illogical.

and maybe it's better in this way

  if fetch(:care_about_ruby_version)
    if installed_version.include?(required_version)
      logger.info "Ruby #{installed_version} matches the required version: #{required_version}."
      return false
    else
      logger.info "Ruby version mismatch. Installed version: #{installed_version}, required is #{required_version}"
      return true
    end
  else
    logger.info "Already installed Ruby #{installed_version}, not #{required_version}. Set :care_about_ruby_version if you want to fix this."
    return false
  end

I have a task similar to this:

namespace :provision do
  task :redis, roles: :redis do
    roundsman.run_list('recipe[redis::server]')
  end
end

And roles like this

role :web, 'web01'
role :app, 'app01'
role :db, 'db01', primary: true
role :redis, 'redis01'

When I run cap provision:redis, I expect it to run recipe[redis::server] only on redis01 host (as per README). Instead, it runs on every host.

  * 01:27:09 == Currently executing `roundsman:chef:chef_solo'
 ** Now running recipe[redis::server]
  * executing "sudo -p 'sudo password: ' chef-solo -c /tmp/roundsman/solo.rb -j /tmp/roundsman/solo.json"
    servers: ["web01", "app01", "db01", "redis01"]
    [db01] executing command
    [web01] executing command
    [redis01] executing command
    [app01] executing command

I made a sanity check by adding this test task.

task :foo, roles: :redis do
  run "echo foo"
end

Running cap foo only ran this task on redis server, as expected.

When unpacking cookbooks, new cookbook directories are simply copied over existing ones. This means, when changing cookbook versions, old files may remain on the remote machine. In my case, this lead to a hard to find bug, where stuff from a leftover libraries file shadowed some newly introduced definitions.

As a quick fix I added a capistrano task which purges the roundsman_working_directory before each run. Either this should be the default behavior or we need a more sophisticated way of removing old cookbooks before unpacking cookbook.tar.

Why is there are requirement for 1.9.2-p192?

There is a package on aptitude with 1.9.2p0. I've used this and it works. Compiling from source takes forever.

From http://www.ruby-lang.org/en/downloads/

Debian GNU/Linux uses the apt package manager system. (So does Ubuntu.) You can use it like this:

$ sudo apt-get install ruby1.9.1
Yes, this will install Ruby 1.9.2. It has a ‘library compatibility version’ of 1.9.1, hence the name.