Bug 1449419

Summary: Document configuring startup order for external resource dependencies
Product: Red Hat Enterprise Linux 7 Reporter: Steven J. Levine <slevine>
Component: doc-High_Availability_Add-On_ReferenceAssignee: Steven J. Levine <slevine>
Status: CLOSED CURRENTRELEASE QA Contact: ecs-bugs
Severity: unspecified Docs Contact:
Priority: high    
Version: 7.2CC: abeekhof, agk, apanagio, c.handel, cluster-maint, cluster-qe, fdinitto, heinzm, jbrassow, jpokorny, kgaillot, kwenning, mnovacek, msnitzer, oalbrigt, prajnoha, prockai, rhel-docs, zkabelac
Target Milestone: rcKeywords: Documentation
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1316130 Environment:
Last Closed: 2017-08-01 16:49:46 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1316130    
Bug Blocks: 1446669    

Comment 2 Steven J. Levine 2017-06-20 20:57:19 UTC
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?

Comment 3 Ken Gaillot 2017-06-21 20:10:49 UTC
(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.

Comment 4 Steven J. Levine 2017-06-26 18:28:15 UTC
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

Comment 5 Ken Gaillot 2017-06-26 19:51:48 UTC
(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.

Comment 6 Steven J. Levine 2017-06-26 21:19:08 UTC
Updates made to the 7.4 draft as per Ken's review.