Role stops service when started by timer

[jstenvall-ducksify]

This PR fixes an issue when this role is executed and any systemd service unit is currently running (i.e. state started). When the role updates its definitions of systemd unit files, it ensures that the running state conforms to the value of unit_item.state or _default_unit_state. This is done in the task titled "Activate configured Systemd units".

Since it is started by a systemd timer and according to the role, it is not supposed to be enabled, hence the service is shutdown. This could happen to any service unit that is supposed to be in a stopped state. This "anomaly" I would like to address in this PR.

When you do not want the role to enforce the state of the service (stopped, started), simply by adding the variable unit_item.manage_state it tells the roles systemd task to either manage the state, or simple omitting the state setting.

unit_config:
  - name: "Test Service"
    manage_state: false
    Unit:
      Description: Service Test
    Service:
      User: test_user
      Group: test_user
      ExecStart: /usr/bin/ls /etc/fstab
    Install:
      WantedBy: multi-user.target
  - name: "Test Timer"
    type: timer
    enabled: true
    state: started
    Unit:
      Description: Timer Test
    Timer:
      OnCalendar: "*-*-* 4:00:00"
      Unit: "test_service.service"
    Install:
      WantedBy: timers.target

This configuration will create a unit with a state that will not be managed by this role since the manage_state is set to false.

We could name the variable enforce_state instead of manage_state.

Fixes #53

[jstenvall-ducksify]

I do not know how to test this new feature.

[O1ahmad]

I do not know how to test this new feature.

Hey @jstenvall-ducksify, nice..thanks for the PR!

With regards to testing, so technically the steps listed in CONTRIBUTING.md should work for local testing. They really just require the installation of a couple of linting tools and having a ruby environment setup to be able to bundle install at repo root in order to pull in all of the ruby related dependencies (e.g. test-kitchen used as the functional/integration testing framework).

If you wouldn't mind trying those steps out locally to verify no regressions then that would be great but no worries if you encounter issues along the way. I think at the very least there may be some changes necessary to ensure the test-kitchen docker driver setup works as expected but otherwise the process should be ok. If so, we should be able to pretty easily add another test to directly verify the new functionality you added.