Document the newly introduced need to specify 'sudo: true'

[eklein]

This broke for me the first time I tried to run test-kitchen and only figured it out because I've been watching the commits.

I can submit a pull request, but I'm not sure if you're planning on doing a larger refactor of the readme.

[fnichol]

Good timing, I'm planning on attacking the README today to get it in shape & up to date.

May I ask where did you have to add sudo: true? Sounds like a default somewhere may not be right. What driver are you using? And workstation operating system?

Thanks!

[eklein]

Sure, I added it under the suite name (not sure if that's the right place or not!):

suites:
  name: default
  sudo: true
  run_list:

Driver is vagrant w/ chef-zero. Running it on OSX 10.9. For what it's worth, it appears to function normally when using chef-solo (without sudo: true).

[fnichol]

Think you could snag the output of a run with chef_zero and the -l debug flag turned on? Maybe this is an edge case I haven't seen yet. Thanks!

[eklein]

ugh.. now i'm running into problems with version constraint problems in berkshelf 2.x.

       ================================================================================
       Error Resolving Cookbooks for Run List:
       ================================================================================


       Missing Cookbooks:
       ------------------
       Could not satisfy version constraints for: my-cookbook

Sigh, can't seem to get past this right now. I'll have to look at it again on Monday.

Another issue I've hit a few times is when the converge fails, TK continues on and attempts to run the tests:

       ================================================================================
       Error Resolving Cookbooks for Run List:
       ================================================================================


       Missing Cookbooks:
       ------------------
       Could not satisfy version constraints for: my-cookbook


       Expanded Run List:
       ------------------
       * chrome


       [2013-11-30T17:51:38+00:00] ERROR: Running exception handlers
       [2013-11-30T17:51:38+00:00] ERROR: Exception handlers complete
       [2013-11-30T17:51:38+00:00] FATAL: Stacktrace dumped to /tmp/kitchen/cache/chef-stacktrace.out
       Chef Client failed. 0 resources updated
       [2013-11-30T17:51:38+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
-----> Shutting down Chef Zero server
       Finished converging <default-centos-64-x86-64> (1m56.38s).
-----> Setting up <default-centos-64-x86-64>...
Fetching: thor-0.18.1.gem (100%)
Fetching: busser-0.6.0.gem (100%)
       Successfully installed thor-0.18.1
       Successfully installed busser-0.6.0
       2 gems installed
-----> Setting up Busser
       Creating BUSSER_ROOT in /tmp/busser
       Creating busser binstub
       Plugin serverspec installed (version 0.2.5)
-----> Running postinstall for serverspec plugin

[fnichol]

Looks to me like you might have forgotten the metadata call in your Berksfile. Give a pure berks install run a show and see if you get the exact same issue. If so, then we're talking about a Berksfile problem or something in Berkshelf itself.

[fnichol]

You could also try blowing away your Berksfile.lock to reforce an unconstrained dependency solution.

[eklein]

Berksfile:

chef_api :config
site :opscode

metadata

Tried nuking the Berksfile.lock and did a fresh berks install.. still came up with unsolvable versions.

[fnichol]

If berks install --path <somewhere> is giving you the same issue, then it's looking like a pure Berkshelf issue… Test Kitchen invokes just enough Berkshelf code to do the dependency resolving.

[eklein]

Sorry, forgot to say that berks install succeeds just fine

[eklein]

Do you want me to open a different issue so this doesn't muddy the original issue here? :)

[fnichol]

In that case, I'm going to pull in bigger guns, @sethvargo, thoughts?

[sethvargo]

@eklein Can you please post your metadata.rb? If this is a public cookbook on GitHub, that'd be awesome. I want to see if I can reproduce this locally.

This very well may be a Berkshelf issue, but I need to figure out exactly what's going on to give you a fix 😄

[nathwill]

not sure if it's the same issue (i'm not using chef-zero), but i'm running into a similar problem with serverspec checking service status... i've tried popping sudo: true, use_sudo: true into as many places in the .kitchen.yml as i can think of, but i'm not seeing the change make it into the busser. reverting f002ae7 and running a patched test-kitchen of course makes the busser run with sudo so the tests pass, but i'm stumped on where this is supposed to be being set now. here's what i've tried so far: https://gist.github.com/nathwill/7741992

result: https://gist.github.com/nathwill/7742030

[fnichol]

Hi all,

It's finally making some sense this morning--seems as though some platforms (CentOS being one of them) may want to do certain Serverspec checks as root. Either because of the path to /sbin/service or other reasons (not too sure at the moment).

Having said that, as of f002ae7 that leaves Test Kitchen less than optimal in the default setup especially when using Busser/Serverspec/CentOS.

So, I'm going to revert this commit so that Busser's behavior is to default sudo: true as before.

For anyone that needs this explicitly set, you can drop in sudo: true into a busser block in your .kitchen.yml in the root of the document, inside a suite, or inside a platform (one of these locations will suffice for most users):

---
driver: vagrant
provisioner: chef_solo

busser:
  sudo: true

platforms:
  - name: centos-6.4
    busser:
      sudo: true

suites:
  - name: server
    busser:
      sudo:true

[bdupras]

@fnichol Yes, the lack of /sbin in the path (e.g. service, chkconfig) was one problem we hit without sudo. Other sudo: false serverspec issues include read access to files, iptable rules, selinux settings, etc.

I don't think that defaulting sudo to false is bad as long as the documentation shows how to configure it.

[fnichol]

@bdupras that's a good takeaway: in either case it needs some documentation. If you ever get curious what the default/set value of this is for your instance, give kitchen diagnose a try. There's a busser block there that will show the value of sudo.

[fnichol]

Just shipping 1.1.0 which updates this default, enjoy!

[juliandunn]

Or "kitchen diganose"

[fnichol]

@juliandunn that's going to take a while to live down 😄

[gsaslis]

thanks for this guys.. was having a very similar issue and even though the correct solution was this one, setting sudo: false also helped to verify the issue...