Add a CentOS 7 Build

[benLogN]

This PR adds a Centos 7 build which uses systemd instead of init.d. There's a few pieces to this change:

1. sensu_configs.rake no longer includes any files into /etc/init.d/
2. Two new recipes (sensu_init.rake and sensu_systemd.rake) now manage placing the service files.
3. The Rakefile now includes different logic based on the init service of the distribution you're building for
4. Systemd init services are used if the build number ends with .el7.

I imagine points one through three will be pretty uncontroversial. Using systemd based on build number, though, could be a point of contention. I chose this strategy because baking the EL major version into the release number (BUILD_NUMBER in the code) seems to be the standard of the CentOS and EPEL packagers. I'd be happy to take suggestions on another approach for picking which builds should use the systemd configs.

[benLogN]

Created in response to the outstanding question on #89

[benLogN]

Bump. Does something need to be changed for this to be merged in?

[portertech]

@benLogN I'll give this a good look shortly, as we revisit packaging for Sensu 👍

[teotwaki]

@portertech What's the status of this? Any chance we could get it landed?

[jrwesolo]

I'd also love to see this!

[benLogN]

Wow, I completely forgot this PR was still out. I'll put in the effort to rebase it if it's likely to get looked at this time...

[jrwesolo]

Thanks @benLogN! That would be awesome!

[benLogN]

I just rebased this. I wasn't able to test that the 32bit releases were unaffected because the 32bit user on docker hub no longer has centos or debian:squeeze releases.

[jrwesolo]

@benLogN Thank you! @portertech What do you think?

[portertech]

Does CentOS 7 provide init.d stubs? I have concerns in regards to documentation, consistency between platforms, and consistency between service managers.

[benLogN]

CentOS 7 doesn't provide init.d stubs, but they do alias the service command to its matching systemd start/stop/restart commands. So /etc/init.d/sensu-client restart would no longer work, but service sensu-client restart would.

[jrwesolo]

@portertech One reason I was hoping for this is because on CentOS 7 using the puppet module sensu-client service enable does not seem idempotent. Every time I rerun on a client, I get:

Notice: /Stage[main]/Sensu::Client::Service/Service[sensu-client]/enable: enable changed 'false' to 'true'

When I manually check, it is always set to enabled. It seems that Puppet is having a difficult time detecting that though. I assume it is because we are not using systemd natively. Everything works correctly on CentOS 6. Have you run into this?

[jrwesolo]

Opened issue in Puppet module as well for tracking: sensu/sensu-puppet#448

[jrwesolo]

@portertech in light of @benLogN's response, what do you need for us to move forward with this? I'll see if I can help out as needed.

[portertech]

@jrwesolo I would really like to see init bin stubs, so documentation is still accurate, and it remains easy to help others regardless of the platform release.

[portertech]

Also, we need to ensure that init functionality and features are the same across all init strategies, e.g. #148

[jaxxstorm]

I'd like to help out here, what's needed to move this forward?

[cwjohnston]

We are currently working to migrate Sensu's build and release process away from the tools in this repo to a toolchain using Chef's Omnibus (see #184).

As part of this process we are planning to drop support for upstart and runit to focus on sysv and systemd as the officially supported service managers (see sensu/sensu-omnibus#34).

I believe these changes will not be necessary for running omnibus builds on Centos 7 and other platforms with systemd as the init system. I've added this PR to the 0.27 milestone to reflect that it is superseded by the switch to omnibus builds which will be used to generate Sensu 0.27 packages.