Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[doc] Issue in "Example cluster configuration" #427

Open
slsnow opened this issue Apr 5, 2024 · 6 comments
Open

[doc] Issue in "Example cluster configuration" #427

slsnow opened this issue Apr 5, 2024 · 6 comments
Assignees
Labels

Comments

@slsnow
Copy link

slsnow commented Apr 5, 2024

Example cluster configuration:
https://documentation.suse.com/sbp/sap-15/html/SLES4SAP-hana-sr-guide-costopt-15/index.html#id-example-cluster-configuration


I'm not sure if I'm misunderstanding this, but I just noticed this in the example cluster configuration in the above docs:

primitive rsc_SAPHana_HA1_HDB10 ocf:suse:SAPHana \
    op monitor interval=61 role=Slave timeout=700 \
    op start interval=0 timeout=3600 \
    op stop interval=0 timeout=3600 \
    op promote interval=0 timeout=3600 \
    op monitor interval=60 role=Master timeout=700 \
    params SID=HA1 InstanceNumber=10 PREFER_SITE_TAKEOVER=false \
        DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=false \
    meta priority=100

In the Azure docs, it's recommended to run:

  • sudo crm resource meta msl_SAPHana_<HANA SID>_HDB<instance number> set priority 100
  • sudo crm configure property priority-fencing-delay=30

Notice that this is the msl_SAPHana..., and not the rsc_SAPHana....

I noticed that even if I were to run this against rsc instead of msl, with crm cli it will apply it to the msl still, and I get the following result:

# crm configure property priority-fencing-delay=30
# crm resource meta rsc_SAPHana_HXE_HDB00 set priority 100
Performing update of 'priority' on 'msl_SAPHana_HXE_HDB00', the parent of 'rsc_SAPHana_HXE_HDB00'
Set 'msl_SAPHana_HXE_HDB00' option: id=msl_SAPHana_HXE_HDB00-meta_attributes-priority set=msl_SAPHana_HXE_HDB00-meta_attributes name=priority value=100
# crm configure show msl_SAPHana_HXE_HDB00
ms msl_SAPHana_HXE_HDB00 rsc_SAPHana_HXE_HDB00 \
        meta is-managed=true notify=true clone-max=2 clone-node-max=1 target-role=Started interleave=true priority=100

Hopefully that makes sense. So, it seems that crm cli is aware, and sets it on the msl_SAPHana, where as if the cib has the priority=100 under the rsc_SAPHana resource manually, it stays there, and is not set to the msl. Wouldn't that lead to an incorrect behavior?

Let me know what you think, if this should be looked into, or if I'm misunderstanding something and this is of no consequence. Thanks.

@chabowski
Copy link
Collaborator

@slsnow thanks for reaching out!
@fmherschel @lpinne would you mind having a look? It is labeled as question for now. Thank you!

@lpinne
Copy link
Contributor

lpinne commented Apr 10, 2024

Hi,
the meta priotity=100 at rsc_, as in the SUSE setup guide, is used by us for testing. We expect this to be used by our customers. If Microsoft describes something different, you might ask them for comments.
Regards,
Lars

@chabowski
Copy link
Collaborator

@slsnow Samuel - does this answer your question? Can I close the issue? Thanks!

@slsnow
Copy link
Author

slsnow commented Jun 13, 2024

Hey, thanks for checking in, and sorry for the slow response. Thanks Lars for the initial comment.

I still think this is not correct though. Regardless of what Azure is doing, as I demonstrated above if you use crm to try to apply that to value rsc_ it gets assigned it to msl_ anyways. This seems unnecessarily confusing, why not assign it to msl_ in the first place? Or is there an actual reason that I'm not understanding, aside from this is "used by us for testing"?

In the long run it might not matter, because in the end the configuration ends up correcting itself. The issue I have is when someone is comparing a cluster configuration post setup, and comparing with the docs in the best practice guide, the value mismatch makes it seem like the configuration doesn't match the documentation.

@chabowski
Copy link
Collaborator

@fmherschel @lpinne any further comment here??

@fmherschel
Copy link
Member

As our solution is working we will not change this "on the fly". I vote closing that issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants