#60 in docker - more clear

[xmik]

This is a better, more clear version of that PR, which you can ignore

Resolved errors

When running in Docker container I ran into those errors:

1. STDOUT: warning: /etc/service/<service_name>: unable to open supervise/ok: file does not exist. Thus I changed the method wait_for_service so that it waits for that file: supervise/ok not only in vm, but also in Docker container. The ruby_block that invokes this method is idempotent and does not go into infinite loop (because of the check if runsvdir process is running (== monitoring a directory with services files)). (runit_service enable failing in docker #60)
2. "fail: <service_name>: runsv not running". It shows that it's not enough to check if supervise/ok exists and thus I added another check, if runsv process is running (== monitoring that one service). Only then the service can be correctly started.

When using runit_service resource in docker container instantiated from Phusion Baseimage, it was enough for me to use only action :enable (without action: start), because the runsvdir is running and should result in starting that service anyway. Using also action :start works too.

Checking, if runsvdir process is running, is crucial in Docker container, because when running kitchen converge, that process is running, but it is not when running docker build.

Tests

I added the Docker platform in .kitchen.yml for integration tests, using kitchen-docker_cli kitchen driver (no ssh here). I ran the tests in Docker container and also in Debian 7.8 virtual machine. In each case there was 1 error:

Failures:

  1) runit_test::service on {:family=>"ubuntu", :release=>"14.04", :arch=>"x86_64"} behaves like common runit_test services creates a service that uses the default svlog Command "file /var/log/default-svlog/*.s" stdout should contain "gzip compressed data"
     Failure/Error: its(:stdout) { should contain('gzip compressed data') }
       expected "/var/log/default-svlog/*.s: ERROR: cannot open `/var/log/default-svlog/*.s' (No such file or directory)\n" to contain "gzip compressed data"
     Shared Example Group: "common runit_test services" called from /tmp/verifier/suites/serverspec/linux_spec.rb:47
     # /tmp/verifier/suites/serverspec/service_example_groups.rb:38:in `block (4 levels) in <top (required)>'

Finished in 4.12 seconds (files took 0.85474 seconds to load)
118 examples, 1 failure

Conclusion

There are comments in code, so I assume no more explanation is needed here.

I depended on this in other cookbooks and it worked.

[coderanger]

This is known, the standard Runit packages all use Upstart or Systemd to launch runsvdir, so when runsvdir doesn't exist the sv command can't do much.

[tomzo]

Is there any reason why this won't get merged? As far as I understand It does not break anything, only fixes runit in docker.

[luckymike]

@tomzo @xmik this will need a rebase before we can consider merging it.

As for any perceived delay, we recently undertook a very large effort to resolve an overly complex change set for this cookbook. We absolutely had to get that out of the way before we could consider additional PRs. Now that that is done, I expect we can review this sometime soon, provided it is rebased to be mergeable.

[tknerr]

Is this still being considered for a merge?

Would love to see this in so we can use it in docker based CI setups with phusion baseimage and the like... :-)

[luckymike]

@tknerr please see: #148 (comment)

We'll absolutely consider it once it is mergeable.

[coderanger]

For anyone that wants to try this now, poise-service-runit supports use inside Docker and LXC.

[tknerr]

@luckymike sorry I overread that

@xmik would be awesome to have that rebased, since this is really essential when integration testing cookbooks that use runit on docker based build systems (e.g. CircleCI)

@coderanger thanks for the pointer, will give it a try!

[xmik]

@tknerr @luckymike @coderanger I rebased #60_in_docker_better branch against develop branch. The rebased branch is called #60_in_docker_better_rebased. I tested it with Test-Kitchen on ubuntu 14.04 docker container and debian-7.8 virtual machine. Same as previously, there is 1 error when running kitchen verify on a service kitchen suite:

Failures:

  1) runit_test::service on {:family=>"ubuntu", :release=>"14.04", :arch=>"x86_64"} behaves like common runit_test services creates a service that uses the default svlog Command "file /var/log/default-svlog/*.s" stdout should contain "gzip compressed data"
     Failure/Error: DEFAULT_FAILURE_NOTIFIER = lambda { |failure, _opts| raise failure }
       expected "/var/log/default-svlog/*.s: ERROR: cannot open `/var/log/default-svlog/*.s' (No such file or directory)\n" to contain "gzip compressed data"
       /bin/sh -c file\ /var/log/default-svlog/\*.s
       /var/log/default-svlog/*.s: ERROR: cannot open `/var/log/default-svlog/*.s' (No such file or directory)

     Shared Example Group: "common runit_test services" called from /tmp/verifier/suites/serverspec/linux_spec.rb:50
     # /tmp/verifier/suites/serverspec/service_example_groups.rb:45:in `block (4 levels) in <top (required)>'

Finished in 4.05 seconds (files took 0.93268 seconds to load)
125 examples, 1 failure

Also, I know I should have stubbed method RunitCookbook::Helpers.runsvdir_running? to always return true, in order to make chefspec tests succeed if ran inside docker container where runit is not installed (like my workstation). I tried different variants, but it just always returned false. So, please be aware of this problem and if someone can fix it, please do.

[luckymike]

@xmik thanks for the new PR. From you comments here and @coderanger's above, it sounds like the above is an expected failure.

Am I correct that this is totally, 100% innocuous in Docker-land? If so, would the correct test resolution be a guard to not attempt that in the Docker context?

Thanks!

[xmik]

@luckymike, I think @coderanger wasn't talking at all about the test-kitchen failure. Rather he was saying why wait_for_service method did not wait inside docker container (it would wait infinitely if runsvdir process is not running, sv command cannot do much then).

The failure happened for me inside docker container with ubuntu and inside virtual machine with debian 7.8 too (I should have written that before). I don't know if this failure is introduced by my PR.

[cwjohnston]

Closing in favor of #193