Add sysvinit/upstart support

[gardar]

Adds support for devices with sysvinit and upstart service managers, made the service templates to be as close to the systemd service as possible.

Been using this internally for months with good success.
I know sysvinit/upstart might be considered legacy by many but I believe this could benefit others with adopting prometheus in their environments.

[paulfantom]

Systemd is a hard requirement for roles in cloudalchemy. Plan is to use even more systemd features and this would conflict with this change. More in #161 (comment)

[gardar]

I understand where you are coming from but systemd and other service managers can coexist in the role quite easily, the systemd specific tasks aren't that many in the role and any future systemd specific ones could simply have a when: ansible_service_mgr == 'systemd' conditional.

This pull request already addresses the points you make in #161 (comment)

• handle few of current preflight checks: https://github.com/cloudalchemy/ansible-node-exporter/blob/master/tasks/preflight.yml#L2-L17

Addressed in: 0c6e877

• Disable creation of systemd file: https://github.com/cloudalchemy/ansible-node-exporter/blob/master/tasks/configure.yml#L2-L9

Addressed in: 7d60fe7

Bear in mind that a plan is to wait for more widespread adoption of systemd version which includes dynamic user feature (I don't remember version now). Which will allow getting rid of user management in this role (those won't be necessary anymore: https://github.com/cloudalchemy/ansible-node-exporter/blob/master/tasks/install.yml#L2-L18)

When that happens we can simply add a when: ansible_service_mgr != 'systemd' conditional to the user creation task. You probably would want to do a conditional for different systemd versions, so skip the user creation task for systemd versions that support the dynamic users and run it with systemd versions that don't.

Additionally, since node_exporter is configured via CLI flags and role won't have any control over those (due to different init system), we are left with a quite complicated role to only download a binary from internet.

I don't see how the CLI flags are a systemd specific option, the templates I created for upstart/sysvinit use the CLI flags, just as the systemd service does.

[paulfantom]

Don't get me wrong, I don't have anything against other init systems. My concern is only about the future of the role and the maintenance toll other init systems bring into this. Which in this case is substantial and can cause confusion in the long run. For example, I am trying in my free time to revive #141 which would bring support for textfile collectors into the role, but it is heavily dependant on systemd timers as those offer a much greater degree of control than simple crontab. Such a feature simply isn't possible in sysvinit or upstart. Hence I am willing to merge this, but under 2 conditions:

1. Support for non-systemd init systems is marked in README as experimental.
2. There is a task (debug) in preflight checks stating clearly that a role is running on system with non-systemd init system and there are no guarantees of this working aka it is experimental.

Additionally to above, CI tests for this feature either need to be switched to a supported system (ubuntu 14.04 is EOL since April 30th 2019) or disabled. I have no intention of supporting an OS just for CI tests :)

[SuperQ]

Like @paulfantom said, 14.04 is EoL. Also CentOS 6 is going EoL in less than a month.

Adding support for EoL systems is a non-goal of this project.

[gardar]

I understand that it can add some maintenance as different init systems support different things (otherwise we wouldn't have multiple init systems in the first place right? :) ).

Currently the systemd/upstart/sysvinit templates all provide a pretty close functionality but if at some point it will move so far apart that it wouldn't make sense to maintain them then this should perhaps be re-evaluated, but let's just cross that bridge when we come to it. (At that point systemd might be even more wide spread than it is now).

Stating that support for non-systemd devices is experimental/without warranty/at own risk in the readme is acceptable to me, a debug message containing the same warning is fine too, and if you want to take it one step further we could even have a bool variable ( yes_i_know_what_im_doing_enable_non_systemd: true ) to enable support for non-systemd devices.

I debated with myself if I should include a dockerfile with centos8/debian10 with sysvinit/upstart or if using a legacy version that came with sysvinit/upstart would make more sense, or even if I should introduce a new distro that ships with sysvinit/upstart that's not already present in the tests.

The reason why I chose CentOS 6 even though it is close to EOL is that rhel6 is still getting extended support from RedHat and will do so until mid year 2024, but I don't think we can run the tests on a rhel6 container without license so running the tests against CentOS 6 would be the next best thing. I don't think running tests on centos 8 with sysvinit will guarantee that the role works on rhel 6.
I believe it's same story is with SLES, SLES11 and 12 have sysvinit and both have extended support for a few more years, but opensuse 11 and 12 are both eol.

(Believe me I wish I would have the luxury of only maintaining the latest distro versions :) but with this at least I'm not stuck with a legacy monitoring system)

[SuperQ]

If we're going to support another process supervisor, supporting Podman/Docker would be preferred over sysvinit or upstart.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[SuperQ]

This role has been deprecated in favor of a the prometheus-community/ansible collection.