Bug 2087726
| Summary: | Add support for in-place upgrade of SAP HANA Cockpit systems | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jesús Serrano Sánchez-Toscano <jserrano> |
| Component: | leapp | Assignee: | Leapp Notifications Bot <leapp-notifications-bot> |
| Status: | NEW --- | QA Contact: | Irina Gulina <igulina> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.9 | CC: | bfinger, fdanapfe, igulina, pstodulk |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Bug | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jesús Serrano Sánchez-Toscano
2022-05-18 11:02:11 UTC
The Leapp Upgrade Tool detects a SAP HANA DB by the presence of /hana/shared/*/exe/linuxx86_64/hdb/sapcontrol as seen here: https://github.com/oamg/leapp-repository/blob/bd85b9bc2ee2d340f8cf875c8b7eeba9aae1f391/commands/command_utils.py#L46 However, the customer who is hitting this has mentioned that the sapcontrol file on a HANA Cockpit system is in /hana/shared/*/*/exe/linuxx86_64/hdb/sapcontrol and that, for some reason, in HANA Cockpit the SAP SID (System ID) is repeated twice in the path. In the system they are trying to upgrade, the path is /hana/shared/SID/SID/exe/linuxx86_64/hdb. I think it would be good to double check (with a test system -I don't have any-) that the System ID is, indeed, repeated twice always in a SAP HANA Cockpit system versus in a SAP HANA non-Cockpit system. I couldn't find any specific reference to that path in the documentation I've provided in the description. As already mentioned via e-mail just checking for the presence of the sapcontrol binary is IMHO not the best approach to detect if SAP HANA or SAP HANA Cockpit are installed on a system
---
On Wed, May 11, 2022 at 2:23 PM Michal Reznik <mreznik> wrote:
Hello Bernd,
@Petr: Is there a way for Leapp to enforce the SAP HANA code path
To quickly unblock them, what if they just touch the file we are checking?
Michal
touching the file might work, but would be a quick and very crude workaround. And this might cause issues later, since the file you are checking for ("sapcontrol") is actually one of the main binaries used for managing a SAP instance. So if the customer forgets to remove the file later on it might lead to all sorts of other issues because other tools might then want to try to use this sapcontrol file as a binary since the might "think" that there is actually a SAP HANA instance installed on the system.
And IMHO just simply checking for the existence of this one binary is not a very good method for detecting if a HANA DB is installed on a system. As the start of the path where that binary is located ("/hana/shared") implies this is actually a directory that can be shared across multiple systems, and not all of them necessarily might have a full HANA DB instance installed, which could lead to Leapp unnecessarily assuming that it needs to use the HANA code-path instead of the regular one in some situations.
Therefore I think it might be better to consider other methods for trying to detect if HANA (or other SAP products like "HANA Cockpit" for example) are installed on a system. As an example for different methods for detecting instances of HANA or other SAP products you could look at the sapnw and saphana plugins used by the "sosreport" tool:
https://github.com/sosreport/sos/blob/main/sos/report/plugins/saphana.py
https://github.com/sosreport/sos/blob/main/sos/report/plugins/sapnw.py
---
|