theforeman / puppet-foreman

Puppet module for Foreman
GNU General Public License v3.0
104 stars 269 forks source link

Let systemd relationship handle dynflow restarts #1148

Open ehelms opened 7 months ago

ehelms commented 7 months ago

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.

ehelms commented 7 months ago

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 https://github.com/theforeman/puppet-foreman/pull/1148#pullrequestreview-1840005272, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACHT47C4K4CB6FEG6HK72LYQAWJTAVCNFSM6AAAAABCHWVARGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTQNBQGAYDKMRXGI . You are receiving this because you authored the thread.Message ID: @.***>

ehelms commented 7 months ago

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:

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.