Bug 690169

Summary: Add chance not to start dlm_controld
Product: [Fedora] Fedora Reporter: Vladislav Bogdanov <bubble>
Component: clusterAssignee: Fabio Massimo Di Nitto <fdinitto>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 13CC: agk, cfeist, fdinitto, lhh, swhiteho
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-03-28 09:49:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Patch to implement
none
Revised patch
none
One more revision none

Description Vladislav Bogdanov 2011-03-23 14:05:25 UTC
Hi,

in some pacemaker-based setups it could be preferred to start dlm_controld, gfs_controld, ocfs2_controld and clvmd not from initscripts, but from pacemaker (as clone resources).

Comment 1 Vladislav Bogdanov 2011-03-23 14:08:18 UTC
Created attachment 487047 [details]
Patch to implement

That functionality is provided by attached patch.

While pacemaker is still tech preview for EL6, it is widely used in Fedora, and latest changes seem to fix cman support issues. This patch allows to go pacemaker-way for cluster management, so pacemaker can manage dlm and dependent resources based on dlm status.

Comment 2 Fabio Massimo Di Nitto 2011-03-23 14:55:02 UTC
We discussed this issue with pacemaker maintainer and it's a non-issue. Documentation for the cman+pacemaker setup has been updated to reflect that dlm* and clvmd will start from init script.

either way I am happy to accept a patch to add the feature, but this patch is just no good.

Look at the runwrap implementation to add the check properly and use a variable  name that is generic. CONTROL_DLM I would expect to drive dlm_controld but not other daemons.

Rather use something like: PACEMAKER_START_DAEMONS (on the same line as "cman start daemons") so that it is clear why it's there and it is generic enough to apply to multiple _controld.

Comment 3 Vladislav Bogdanov 2011-03-23 15:12:06 UTC
Will CMAN_START_DAEMONS with default "yes" be OK?

Comment 4 Vladislav Bogdanov 2011-03-23 15:48:08 UTC
Created attachment 487078 [details]
Revised patch

What about this one?

BTW, stop operation for ocfs2_controld is missing.

Comment 5 Fabio Massimo Di Nitto 2011-03-23 15:57:22 UTC
This is a lot better.

For a matter of consistency, please just add a dlm_controld_enable function that wraps controld_daemons_enabled.

Yes that is correct, we don't stop ocfs2_controld. The start in cman is a special case to workaround possible init script bad ordering.

If ocfs2 is started before cman, ocfs2_controld will fail, so cman will check for that and start it (see ocfs2_controld_enabled).

In case ocfs2 start after cman, then it's all good because ocfs2 will find ocfs2_controld already started and do the right thing.

In shutdown, the problem doesn't exists because cman will refuse to exit if ocfs2_controld is still running.

Comment 6 Vladislav Bogdanov 2011-03-23 16:12:18 UTC
Created attachment 487085 [details]
One more revision

This one should be it. I hate implicit returns so I added return $?. Can be dropped if you prefer.