sap_ha_pacemaker_cluster: fix NWAS #972
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The SAPStartSrv monitor operation should not run on an interval, only for a probe once at start. The added operation parameters will make sure that the monitor operation is disabled. To make it very clear that the interval=0 is not a mistake, the `enabled` parameter is set to `false` as well.
ja9fuchs
force-pushed
the
fix-nw-sapstart
branch
from
61ead46 to
a968d1f
Compare
|
Pushed a fix and included a bunch of additional tags to be able to run only the preparations and ha_cluster. |
ja9fuchs
force-pushed
the
fix-nw-sapstart
branch
from
acb63b4 to
e39ab94
Compare
ja9fuchs
changed the title
- Instance systemd registration is now only run when the systemd service does not exist yet. This prevents unnecessary re-registration. - Some tasks were moved from post-installation to pre-installation, to safely run them before the cluster is installed. This prevents some conflicts that occur after the cluster already has control over the instances.
ja9fuchs
force-pushed
the
fix-nw-sapstart
branch
from
e39ab94 to
71876df
Compare
Creating the (optional) ha_cluster parameter config file is now part of the steps run before the actual cluster installation and included in the "pre_ha_cluster" tag. Previously it was run at the very end and if a post-step failed the config review file would be missing.
Previously, if the host_type contained a HANA type it would also include the vars file here. This change limits the scope to NWAS types.
The connector package is now added with a conditional to the 'nwas' package dictionary key. It did not work in the nwas vars combination task.
Not a real issue, but it is cleaner to remove the maintenance attribute when it is disabled and not display it anymore.
|
A few more fixes added. Some others are still being clarified. |
- additional resource cleanup task before the restarts take place - restart SAPInstance resource, not SAPStartSrv, unrelated to simple mount
marcelmamula
approved these changes
Feb 25, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix: SAPStartSrv monitor
The SAPStartSrv monitor operation should not run on an interval, only for a probe once at start. The added operation parameters will make sure that the monitor operation is disabled.
To make it very clear that the interval=0 is not a mistake, the
enabledparameter is set tofalseas well.Before:
After:
This resulting config remains active on RHEL.
Currently the SUSE post-inst deletes all operations afterwards, so this change should not make any difference there.
Reference:
Fix: NWAS pre/post workflow
New file for NWAS (A)SCS/ERS pre-steps for changes to be run before the cluster is installed.
This contains...
Instance systemd registration is now only run when the systemd service
does not exist yet. This prevents unnecessary re-registration.
Some tasks were moved from post-installation to pre-installation, to
safely run them before the cluster is installed. This prevents some
conflicts that occur after the cluster already has control over the
instances.