[New Repository] resource-agents.saphanasr-angi

[ja9fuchs]

[New Repository] resource-agents.saphanasr-angi

Proposed repository name

resource-agents.saphanasr-angi

Repository type

Cluster resource agents and SR hook scripts - Pacemaker OCF resource agents for SAP HANA System Replication high-availability clusters (scale-up and scale-out), angi generation.

Link to existing repository

https://github.com/ja9fuchs/resource-agents.saphanasr-angi

---

Purpose

SUSE/SAPHanaSR is the canonical upstream for Pacemaker resource agents for SAP HANA and SAP HANA SR hook scripts. It is maintained as a SUSE product repository, with SUSE-specific naming conventions, packaging assumptions, and man page content baked in.

SAP certifies its HANA HA solution on both SLES and RHEL and expects to ship the same functionality on both. Currently, the necessary changes to make the upstream content distribution-neutral are applied directly inside the Red Hat dist-git, making the delta invisible to customers and to SAP.

This repository provides a vendor-neutral, distribution-agnostic view of the same content:

• SUSE-specific hook class names (susHanaSR, susTkOver, susChkSrv) replaced with neutral names (HanaSR, TkOver, ChkSrv)
• SUSE-specific man page content and cluster configuration examples excluded
• Content tracked against upstream via a sync script; deviations explicitly documented with reasons
• CI checks (shellcheck, pylint, perlcritic) enforce results - upstream runs the same linters but silently ignores most failures, reporting all checks as passed

The repository is not a fork. Feature development belongs upstream in SUSE/SAPHanaSR. This is the transparent, maintainable layer between upstream and distribution packaging. sap-linuxlab is the natural home for SAP-centric content maintained across distribution boundaries.

Naming prefix proposal: resource-agents.*

No existing sap-linuxlab prefix fits this content type:

• community.* - Ansible Collections
• tool.* - standalone scripts/utilities
• terraform.*, demo.* - other specific types
• high-availability.* - can mean other than cluster, requires adding the "resource-agents" part to the repo name for clarity and makes it unproportionally long

I propose resource-agents.* as a new prefix category for Pacemaker OCF resource agent repositories. This directly follows the naming conventions used by ClusterLabs (resource-agents, fence-agents, alert-agents) and is clear to cluster and non-cluster audiences alike.

More repositories of this type are planned. A consistent prefix now avoids naming inconsistency later.

License

GPL-2.0-or-later, inherited from SUSE/SAPHanaSR. Relicensing is not possible without SUSE's agreement. GPL is already present in the sap-linuxlab organization (tool.sapcontrol-bash-completion, tool.cg_elimit, community.sap_ha_cluster_qa).

Pre-submission checklist

• Code has been human-reviewed; maintainer understands the content and accepts responsibility
• README and comments are in English
• README follows the closest applicable template with gaps noted
• Supported platforms documented (distribution-neutral content)
• Testing coverage and limitations documented
• License in place (GPL-2.0-or-later)
• Repository name follows naming conventions - prefix resource-agents.* proposed above, pending Governance Board confirmation

[berndfinger]

@ja9fuchs Great work! I fully agree with the above approach, which appears to be the best solution until at some point in time there might be a vendor-neutral upstream repo. I support adding this repo to the sap-linuxlab GitHub organization.

[gereonvey]

Hi @ja9fuchs,

Let me comment on a few things here:

SUSE/SAPHanaSR is the canonical upstream for Pacemaker resource agents for SAP HANA and SAP HANA SR hook scripts. It is maintained as a SUSE product repository, with SUSE-specific naming conventions, packaging assumptions, and man page content baked in.

Yes, SUSE/SAPHanaSR is the canonical upstream because SUSE developed this initially. In the true spirit of open source it has been licensed under GPLv2. SUSE employees maintain this repository actively and it is used for our product, with everything we think belongs to it (e.g. man pages). Red Hat (and anyone else) is free to collaborate there, or to fork this and use it in accordance with GPLv2.

SAP certifies its HANA HA solution on both SLES and RHEL and expects to ship the same functionality on both.

SAP haven't been (re-)certifying HA solutions for SAP HANA in a good while. When SAP certified HA solutions for SAP HANA, they certified vendor-specific solutions, there was never the expectation that these solutions were consistent across vendors, and the certification covered more than just the code, including inherently vendor specific things (support process etc.). There were other vendors besides SUSE and Red Hat, with completely different, certified HA solutions for SAP HANA.

This repository provides a vendor-neutral, distribution-agnostic view of the same content:
[...]
The repository is not a fork.

Due to the modifications, the repository represents a “work based on the Program” and is IMHO (IANAL) in violation of the following clause of the license in section 2 of the GPLv2:

a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

I don’t see any such notices in the files of the proposed repository.

While we are at licenses: According to https://sap-linuxlab.github.io/initiative_about/ all repositories should be provided under the Apache 2.0 license, which the proposed repository is not.

This repository provides a vendor-neutral, distribution-agnostic view of the same content:
[…]

• SUSE-specific man page content and cluster configuration examples excluded

Removing important config information, maintenance procedures will confuse the customers who are already using the software, will lead to loss of information and is counter-productive. The cluster solutions (base framework) of SUSE and RedHat have so many differences in details, that solution specific configurations need to be provided to be able to set it up correctly, do valid maintenance and to allow checking the cluster configuration. Even if this repository would serve as an upstream, is removing information which is vital to understand how the code is supposed to work a good idea?.

The repository is not a fork. Feature development belongs upstream in SUSE/SAPHanaSR. This is the transparent, maintainable layer between upstream and distribution packaging. sap-linuxlab is the natural home for SAP-centric content maintained across distribution boundaries.

If this repository does not do any development or fixes, it becomes a slightly different mirror of actual upstream, just without actual history of work and effort that was put into maintaining and growing upstream. Since SUSE will continue using resource agents from the SUSE organization, I don’t see a purpose for hosting this purposely incomplete and modified mirror repository in the SAP LinuxLab organization. Who would benefit from that?

I propose resource-agents.* as a new prefix category for Pacemaker OCF resource agent repositories. This directly follows the naming conventions used by ClusterLabs (resource-agents, fence-agents, alert-agents) and is clear to cluster and non-cluster audiences alike.

SAPHanaSR contains both resource and alert agents, not just resource agents.

In general, I struggle to understand why we should host this repository in the SAP LinuxLab organization.

• It’s not going to be a collaborative upstream project (that would be SUSE/SAPHanaSR), as stated in the original request
• It’s not a clean fork of upstream, which you could argue to be beneficial for discovery
• Licensing is not according to our standards (wrong license, not respecting the upstream license)
• Repository naming is not according to upstream (ClusterLabs) standards
• Unclear purpose. Who/What is this for?

As it is now, I do not support adding this repo to the sap-linuxlab GitHub organization. I guess we need to discuss this more in our next governance board meeting

Best regards,
Gereon

[marcelmamula]

My vote: No

Reason:

• Gereon laid out most of concerns above and I agree with them.
• On top of that I see more issues with GPL-2 licensing as well, because:
  • Modified files are not commented in header that they were modified.
  • Lot of folders were removed, without documenting them or why it was done. It is hidden in transformation script.
  • Removal of documentations in /man is bad idea.

It says in documentation that /man is not synced, but that just means throwing away years of knowledge and experience that went into creating those extensive documents. Metadata cannot contain all this information.

# man/ is NOT synced from upstream.
# The three RA parameter pages (ocf_heartbeat_SAPHana{Controller,Filesystem,Topology}.7)
# are auto-generated from RA metadata via the ClusterLabs resource-agents toolchain and
# committed as static files.  Update them manually when RA parameters change significantly.

[ja9fuchs]

SUSE is welcome to contribute to the neutral repository and help create the neutral man pages or anything else you find missing currently.

Is a new repository under sap-linuxlab only approved when it is complete and perfect already? Or is it allowed to start with a minimal common base and enhance it over time?

There are other GPL repos under sap-linuxlab.
GPL-2.0 allows sub-sets and modifications.

The human readable files in this repo contain documentation of the modifications.
I can add the functional modifications to the file headers if that is a requirement.

[ja9fuchs]

@gereonvey @marcelmamula
What would a repository have to look like, that places the SUSE/SAPHanaSR repo content under sap-linuxlab in a vendor-neutral way and satisfies the SLL initiative?
Currently the SUSE RA repos are maintained consistently outside the SLL as development repos that double as vendor product source at the same time.

If you think that resource agents developed by SUSE do not qualify to be maintained under SLL because SUSE prefer to manage them vendor-based, please be honest about it and we save a lot of headache here.

[marcelmamula]

@ja9fuchs I second motion to discuss it in detail during next Governance meeting, because going in details in this thread will not achieve resolution.

About your last comments:

SUSE is welcome to contribute to the neutral repository and help create the neutral man pages or anything else you find missing currently.

• SUSE already has valid man pages and documentation. It would not serve much purpose to rebuild everything from scratch and then go back and forth with every update in SUSE upstream to reflect it back.

Is a new repository under sap-linuxlab only approved when it is complete and perfect already? Or is it allowed to start with a minimal common base and enhance it over time?

• Perfection is not requirement, but fulfilled mandatory baseline is - be it in terms of quality and contents. We recently updated requirements for onboarding new repositories and new candidate repo is being subjected to those standards.

GPL-2.0 allows sub-sets and modifications

• Sure, but with limitations. Files can be removed if explained correctly, but all modifications must follow 2.a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
• Broad statement for modifications in README does not quality and fulfill GPL-2 2.A section.

What would a repository have to look like, that places the SUSE/SAPHanaSR repo content under sap-linuxlab in a vendor-neutral way and satisfies the SLL initiative?
If you think that resource agents developed by SUSE do not qualify to be maintained under SLL because SUSE prefer to manage them vendor-based, please be honest about it and we save a lot of headache here.

• Correct upstream > downstream requires neutral upstream, which is not the case for these agents. Unless authors of this code allow transfer of ownership somewhere neutral like Cluster Labs then do changes in downstream, there is no point in discussing moving to SLL in discussion thread like this.

Currently the SUSE RA repos are maintained consistently outside the SLL as development repos that double as vendor product source at the same time.

• Repository SUSE/SAPHanaSR pre-dates SLL project, so this is expected.

[ja9fuchs]

All newer RA repos have been created by SUSE in the same way, even after the SLL initiative existed. I understand it is convenient and the SLL initiative is only a suggestion for those who want to participate.

This would not be the only repo I'd like to create this way for the resource agents that are currently SUSE-owned vendor sources.

Correct upstream > downstream requires neutral upstream, which is not the case for these agents. Unless authors of this code allow transfer of ownership somewhere neutral like Cluster Labs then do changes in downstream, there is no point in discussing moving to SLL in discussion thread like this.

If a "transfer of ownership" of the code by the authors is a requirement to place a neutral version of the repo under SLL (where neutral SAP-related content is suggested to be maintained), and SUSE is not willing to do that, then I agree, there is no point in discussing this further.