Fixes #18757 - Handle dynflow service in foreman core #602
Conversation
|
@ekohl, the Redmine ticket used is for a different project than the one associated with this GitHub repository. Please either:
If changing the ticket number used, remember to update the PR title and the commit message (using This message was auto-generated by Foreman's prprocessor |
ekohl
force-pushed
the
dynflow-in-core
branch
from
56384b1
to
67e85b5
Compare
ekohl
changed the title
|
@mmoll I'm looking at merging the RPM packaging PR. Is there anything that should be done for the deb side? |
|
Something like theforeman/foreman-packaging#1549 would need to get added to the DEB package also... |
|
If the service is also called "dynflowd" on Debian, this should work OOTB, AFAICT 👍 |
|
I'll have a look at adding dynflowd to Debian. It was my intention to unify them and simplify our instructions/packaging/configuration. |
The dynflow service was moved into core with 1.17. That renamed it to dynflowd and means the service should be started by default. For compatibility parameters are provided. This means we must move the service name detection to the jobs.pp file because that's the only place we know the actual value.
ekohl
force-pushed
the
dynflow-in-core
branch
from
67e85b5
to
ee1b7b4
Compare
|
Rebased and updated to state it's 1.17+. Now that it's in both debs and rpms this can be merged once tests pass. |
The dynflow service was moved into core with 1.16. That renamed it to dynflowd and means the service should be started by default.
For compatibility parameters are provided. This means we must move the service name detection to the jobs.pp file because that's the only place we know the actual value.
This replaces #530. It's mostly the same, but split into two commits to make reviews easier. The first is a compatible refactor where the second is just the introduction of dynflow in core.