Let systemd relationship handle dynflow restarts

[ehelms]

When all services are stopped, a puppet run of this module (or the installer) will trigger services to start back up. Since I believe Puppet detects this as the start, this results in a restart of Foreman and Dynflow:

[28.25 seconds] /Service[foreman]:
[27.37 seconds] /Service[dynflow-sidekiq@orchestrator]:
[26.42 seconds] /Service[dynflow-sidekiq@worker-hosts-queue-1]:
[26.32 seconds] /Service[dynflow-sidekiq@worker-1]:

Via systemd relationships, dynflow is already part of Foreman (https://github.com/theforeman/foreman/blob/develop/extras/systemd/dynflow-sidekiq%40.service#L5) which means that anytime foreman.service receives a restart the dynflow* services will also get restarted. By allowing systemd to control this rather than Puppet, we can save ~1.5 minutes on my test system.

[ekohl]

I'd think that if we make it require the Foreman service that the ordering means it'll already be running by the time it's evaluated, making it a noop

[ehelms]

I tried that first and did not see the expected behavior.

…

On Tue, Jan 23, 2024, 4:52 PM Ewoud Kohl van Wijngaarden < ***@***.***> wrote: ***@***.**** commented on this pull request. I'd think that if we make it require the Foreman service that the ordering means it'll already be running by the time it's evaluated, making it a noop — Reply to this email directly, view it on GitHub <#1148 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACHT47C4K4CB6FEG6HK72LYQAWJTAVCNFSM6AAAAABCHWVARGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTQNBQGAYDKMRXGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[evgeni]

What does ensure => true mean?

https://www.puppet.com/docs/puppet/8/types/service.html#service-attribute-ensure is not exactly verbose on that.

[evgeni]

According to https://github.com/puppetlabs/puppet/blob/3192f4aab419b221402f738ed1be90de0d969be5/lib/puppet/type/service.rb#L114 it should not be a change at all?

[ehelms]

Yea.. weird I dunno why I thought I saw this work and then couldn't reproduce it. Digging through some history, I see this was brought up in the original systemd change:

• Fixes #33723 - Make dynflow-sidekiq services PartOf foreman.service foreman#8856 (comment)
• https://projects.theforeman.org/issues/33725

I think the part that has me confused the most, and our use cases is PartOf declaration and it's caveat that it only works for stop and restart. Although from my testing restart doesn't always work. If foreman is stopped and you issue a restart it won't affect dynflow. I assume this is because it's actually the "stop" aspect that triggers the relationship.

Letting systemd perform actions in parallel though is more efficient than what currently appears to happen with Puppet.

[ekohl]

I think the real cause isn't the ensure but that there's a refresh relationship.

On line 55 there's a Service <| tag == 'postgresql::server::service' |> ~> Service[$service]. This is because dynflow doesn't handle PostgreSQL reconnects, at least didn't in the past. That is one possible issue.

It may also be because of the config file on line 48, though we can't get rid of that.

The other one I'm uncertain about is how foreman::service propagates refreshes to foreman::dynflow::pool and that pool to individual workers.

I think debug logs tell you when a resource triggers a refresh.