(Re-)start service with notify

[wsmirnow]

It is a good idea using Ansible good practices re-/starting services only if needed. This should be done with notify.

[lkiesow]

This doesn't make sense to me.

• A Debian package install should automatically start the service. But why should this trigger an additional restart?
• Similar for RPMs: It doesn't start automatically for an install, but would do a restart on update if necessary. Why should ansible trigger an additional restart?
• You removed state: started. Ansible should describe the expected state. At the end of the run, I expect the service to be started. If I stop the service and then run the script, with your changes, you wouldn't get a running OpenSearch.

[wsmirnow]

This doesn't make sense to me.

But it is. Not using the power of notify/handlers in Ansible is like not using a for-each loops in any programming language.

• A Debian package install should automatically start the service. But why should this trigger an additional restart?

Yes, at least with the PR #4 (after your requested change installing plugin with OS package manager). Let me give you an example. You upgrade your Opencast instance from OC <17 to 17. Opensearch is already installed. But #4 will also install the alnalysis-icu plugin. Not having a restart-service notify will end up with running service (due to service state=started) but the plugin is not loaded. With notify, any installation (including dependencies and plugins) will trigger an restart as it should. For Debian it is possible to change the start-service-on-install Policy globally if you want (look somewhere here). Force starting the service (and not follow the System policy) is not a good practice.

• Similar for RPMs: It doesn't start automatically for an install, but would do a restart on update if necessary. Why should ansible trigger an additional restart?

Same as for Debian.

• You removed state: started. Ansible should describe the expected state. At the end of the run, I expect the service to be started. If I stop the service and then run the script, with your changes, you wouldn't get a running OpenSearch.

Yes, I would also expect a running service at the end of the playbook run (or at least at the end of the block). And this is the case. The difference is, the service will be started with the new configuration at the end of the Ansible block, not the Ansible role assignment. Then you have a chance to configure it properly before the first run. An other real example: An elasticsearch package (not tested opensearch yet) from OC repo runs fine on EL9 instances. But in some cases the system policy forcing /tmp to reject executable files (and directories?). This will break the elasticsearch service (maybe opensearch as well). Setting tmp storage dir for the service to be /var/lib... will do the job but this must be done before starting the service. If the role force start the service at the end, this will fail and the playbook as well. Using notify will trigger the first service start at the end of the Ansible block. Then you can apply your configuration before handler were running like this:

- name: Setup OpenSearch
  hosts: opensearch
  roles:
    - elan.opencast_opensearch <--will trigger restart service
    - opensearch_org_settings <--will trigger restart service
  <-- The triggers will be applied here

If you stop the service manually, then it is on your own starting it again. Ansible is not a tool to monitor the state. Please use an other tool (e.g. Puppet) for that kind of automation.

[lkiesow]

Maybe let's have a meeting in the next days. I see why you want the forced restart with the newly required analysis-icu plugin. But maybe something like this is actually a better way:
opencast/opencast-rpmbuild@098f3b6

Let's have a chat, discuss and figure out together what the best way is.

[lkiesow]

Removing this means that if I go to my OpenSearch server run systemctl stop opensearch and later run this role to ensure everything is set up correctly, OpenSearch will not be started. That probably shouldn't be.