Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Ken:
I've read through the entire exchange now and ultimately all I really had to do was read your summary -- although it was useful to me to see that you are separating out the dependency from anything within Pacemaker itself, after all that discussion of how Pacemaker might handle it.
I'm thinking about where this might belong in the Pacemaker Reference -- I think it would be easier to find there at this point than if we made it a separate article, although in the idealized future we will have better ways of connecting all of those pieces. Possibly as an advanced topic, possibly as an appendix (although it hardly seems long enough to warrant being its own appendix).
I have a question. You note:
---
If the cluster has a resource that depends on the external service "foo"
that is not managed by the cluster, the user should create a drop-in
/etc/systemd/system/resource-agents-deps.target.d/foo.conf containing
the following, and then run "systemctl daemon-reload":
[Unit]
Requires=foo.service
After=foo.service
That is just an example; individual users' needs may vary. For example,
someone may have a disk mount as a dependency instead of a service.
---
But if it's a disk mount, or something that is not a service, how would you specify it in a .conf file?
(In reply to Steven J. Levine from comment #2)
> Ken:
>
> I've read through the entire exchange now and ultimately all I really had to
> do was read your summary -- although it was useful to me to see that you are
> separating out the dependency from anything within Pacemaker itself, after
> all that discussion of how Pacemaker might handle it.
>
> I'm thinking about where this might belong in the Pacemaker Reference -- I
> think it would be easier to find there at this point than if we made it a
> separate article, although in the idealized future we will have better ways
> of connecting all of those pieces. Possibly as an advanced topic, possibly
> as an appendix (although it hardly seems long enough to warrant being its
> own appendix).
>
> I have a question. You note:
>
> ---
> If the cluster has a resource that depends on the external service "foo"
> that is not managed by the cluster, the user should create a drop-in
> /etc/systemd/system/resource-agents-deps.target.d/foo.conf containing
> the following, and then run "systemctl daemon-reload":
>
> [Unit]
> Requires=foo.service
> After=foo.service
>
> That is just an example; individual users' needs may vary. For example,
> someone may have a disk mount as a dependency instead of a service.
> ---
>
> But if it's a disk mount, or something that is not a service, how would you
> specify it in a .conf file?
Systemd provides its own syntax for specifying such things, so it's just a matter of replacing "foo.service" with the desired systemd unit name. For example, to mount /srv, someone would create a systemd file "srv.mount" with the appropriate information per the systemd documentation, then put "srv.mount" in the .conf file to make sure pacemaker starts after it's mounted.
(In reply to Steven J. Levine from comment #4)
> Ken:
>
> I wrote something up -- pretty much your summary description -- and put it
> in the RHEl 7.4 draft of the Pacemaker manual as section 9.6:
>
> http://jenkinscat.gsslab.pnq.redhat.com:8080/job/doc-
> Red_Hat_Enterprise_Linux-7-High_Availability_Add-On_Reference%20(html-
> single)/lastSuccessfulBuild/artifact/tmp/en-US/html-single/index.html#s1-
> nonpacemakerstartup-HAAR
>
> Could you review that?
>
> Steven
Looks good, but I would clarify the disk mount example, something like:
"For example, you may have a dependency on mounting a file system at /srv, in which case you would create a systemd file srv.mount for it according to the systemd documentation, then create a drop-in as described here with srv.mount in the .conf file instead of foo.service, to make sure that Pacemaker starts after the disk is mounted."
The important parts being that systemd requires that the name of the .mount file match the path where the file system should be mounted, and that how to write the .mount file is documented elsewhere.