Adapt checks to Pacemaker 3 - #83
Conversation
Signed-off-by: Antonio Gamez Diaz <antonio.gamez@suse.com>
Signed-off-by: Antonio Gamez Diaz <antonio.gamez@suse.com>
Signed-off-by: Antonio Gamez Diaz <antonio.gamez@suse.com>
| - name: col_with_rsc_role | ||
| customization_disabled: true | ||
| default: "Promoted" | ||
| conditions: | ||
| - value: "Master" | ||
| when: env.architecture_type == "classic" | ||
| - name: msclone | ||
| customization_disabled: true | ||
| default: "clone" | ||
| conditions: | ||
| - value: "master" | ||
| when: env.architecture_type == "classic" |
There was a problem hiding this comment.
This is just for saying: if "classic" --> use old names; if "angi" --> use new ones ... but I think we can support old/new Pacemaker terminology without tying it up to a certain version of our resource agent.
There was a problem hiding this comment.
Instead of only considering facts.resources.master we just find the promotable clones, as it is the new syntax.
| for prim in rsc { | ||
| if prim.type == "SAPHana" { | ||
| let op = prim.operations.op.find(|oname| oname.name == "monitor" && oname.role == "Master"); | ||
| let op = prim.operations.op.find(|oname| oname.name == "monitor" && (oname.role == "Master" || oname.role == "Promoted")); |
There was a problem hiding this comment.
And this is another change to support Master and the new one Promoted.
|
I am not sure what to do with this PR @antgamdia . From the code itself I cannot tell whether the changes will work or not. I would have to deploy clusters using the new terminology and test the changes against them. But I don't have the bandwidth to do that right now. |
arbulu89
left a comment
arbulu89
left a comment
There was a problem hiding this comment.
@antgamdia
All of this changes depend on new pacemaker attributes and values, right?
I think a better approach would be to send pacemaker version as metadata, and based on that, change the values with the when clause.
Most of the code could would look cleaner.
Anyway, it might not fix all the issues and some check changes are needed
No worries, I just added you for awareness. Nothing actually is required at the moment.
Partially. Some changes have been around for some time, like the promotable clones (since That said, I'm not an expert on writing checks, so up to the checks team's preference :P |
3 participants
Description
This pull request refactors several check files to enhance compatibility and robustness for old and new Pacemaker versions.
<master>to<clone promotable=true>syntax, that is, wherever we used.master, now we filter by promotable clones instead.master/slave) and new roles (promoted/unpromoted).Specifically:
Refactoring for Promotable Clone Support:
AE0C5F.yaml,AE0C60.yaml,AE0C61.yaml,AE0C62.yaml,AE0C63.yaml,AE0C64.yaml,AE0C65.yaml,AE0C67.yaml,AE0C6A.yaml, andAE0C6B.yamlto aggregate bothmasterresources andcloneresources flagged as promotable, ensuring checks apply to all relevant resource types.Role Name Compatibility:
"Master"and"Promoted"(and"Slave"and"Unpromoted") as valid operation roles when searching for monitor operations, improving compatibility with different resource configurations. [Colocation Constraint Handling:
col_with_rsc_roleandmsclonein3D8598.yaml, and updated colocation constraint checks to accept either"Promoted"or"Master"as thewith-rsc-role, making the check less brittle.Related #TRNT-4562
How was this tested?
N/A
Documentation changes
No
Additional information
Related to #77