Fix CentOS7 rabbitmq build failure

[arm4b]

From the Travis log, the build started to fail on March, 17, while previous good buld was on March, 15.

CentOS7 Build Error:

* service[rabbitmq-server] action start[2017-03-30T08:16:05+00:00] INFO: Processing service[rabbitmq-server] action start (rabbitmq::default line 235)

No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.

Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received

The build has been terminated

From the official rabbitmq chef cookbook https://github.com/rabbitmq/chef-cookbook/releases, the breaking change release that happened during that time period could be v4.11.0 with the following diff: https://github.com/rabbitmq/chef-cookbook/compare/v4.10.0...v4.11.0#files_bucket

Sadly, official rabbitmq cookbook CI is all red for a long time :cry: :-1:

---

Experimenting to figure out the fix.

[shortdudey123]

Not sure that this is a bug in the cookbook itself. test-kitchen on vagrant for Centos 7.2 converges on master right now. I would guess it is probably on the docker side only??

Excerpt from bundle exec kitchen test default-centos-72

       Chef Client finished, 77/132 resources updated in 14 minutes 07 seconds
       Finished converging <default-centos-72> (17m41.86s).
-----> Setting up <default-centos-72>...
       Finished setting up <default-centos-72> (0m0.00s).
-----> Verifying <default-centos-72>...
       Preparing files for transfer
       Transferring files to <default-centos-72>
       Finished verifying <default-centos-72> (0m0.00s).
-----> Destroying <default-centos-72>...
       ==> default: Forcing shutdown of VM...
       ==> default: Destroying VM and associated drives...
       Vagrant instance <default-centos-72> destroyed.
       Finished destroying <default-centos-72> (0m9.02s).
       Finished testing <default-centos-72> (19m0.40s).

[arm4b]

Yeah, this looks like related to systemd + Docker.

From what I see rabbitmq definitely did a lot of systemd packaging changes recently. Also they split one EL rpm package and started building separated packages for el6/el7 (compare https://www.rabbitmq.com/releases/rabbitmq-server/v3.6.5/ vs https://www.rabbitmq.com/releases/rabbitmq-server/v3.6.6/).

I hope rabbitmq cokbook guys will make their tests green someday so we could use latest cookbook version: https://travis-ci.org/rabbitmq/chef-cookbook

But for now we need the tests green in our repo, so pinning cookbook version to latest "working".

[shortdudey123]

Interesting, probably would be a good idea to add a comment in metadata.rb as to why the version pin is there so people can see it when they look at it as opposed to the git/PR history.

I am working on fixing the RMQ cookbook tests so hopefully that should be good by Monday

[arm4b]

@shortdudey123 Sounds cool! Good luck with that, - it definitely won't be an easy task.

I just added a code comment to explain the reasons why we use/pin that cookbook version.

[shortdudey123]

Cool, can you squash the commits? will approve after that

[arm4b]

I'd like to keep that history where I experimented with versions and things like https://github.com/StackStorm/chef-stackstorm/pull/62/commits/5577f7c488bc9a4d7e4ddcc4d8ecb0a18407af55.

I have a feeling that history would be useful for me in a couple of months or so if I'll need to return to RabbitMQ experiments once they release new versions.

[shortdudey123]

FYI... rabbitmq cookbook should get a major version bump and release in the next day or so

[arm4b]

Cool! Thanks for your efforts!