Closed lpalovsky closed 3 years ago
Hey @lpalovsky , Thank you for the report. I have been able to reproduce even in SLE15SP2. The truth is that we had this issue in the past (at least something similar), and the unique thing we just do is to replicate what the best practices guide say at that time. Now I have realized that the latest cost-optimized guide has some different steps, but all of them are lead to the same error. https://documentation.suse.com/sbp/all/single-html/SLES4SAP-hana-sr-guide-CostOpt-12/
I don't know if I will be able to fix this. @fmherschel and @pirat013, could you help on this?
Edit.
After a quick test, I think that our srTakeover
hook python script shouldn't import the python dbapi
library as it does. It should do from hdbcli import dbapi
. The hdbcli
package is already installed in the SAP python environment and importing this way we don't have the Attempted relative import in non-package
error.
In fact, with this way, we shouldn't even need the links of the python files in the folder neither.
I didn't test all of this deeply anyway
I can confirm the behavior and the error messages about the import:
prdadm@vmhana02:/usr/sap/PRD/HDB00/vmhana02/trace> tail -f nameserver_alert_vmhana02.trc
[26968]{-1}[-1/-1] 2021-06-08 12:33:03.350017 e ha_dr_provider PythonProxyImpl.cpp(00091) : import of srTakeover failed: srTakeover.py(43): Attempted relative import in non-package
[26948]{-1}[-1/-1] 2021-06-08 12:33:03.350209 e ha_dr_provider HADRProviderManager.cpp(00081) : could not load HA/DR Provider 'srTakeover' from /hana/shared/srHook
[26948]{-1}[-1/-1] 2021-06-08 12:33:03.350666 f NameServer TREXNameServer.cpp(03884) : exception 1: no.7010003 (TREXNameServer/TREXNameServer.cpp:1569)
abort
exception throw location:
1: 0x00007f478d067c4c in NameServer::AbortException::AbortException(char const*, int, ltt_adp::basic_string<char, ltt::char_traits<char>, ltt::integral_constant<bool, true> > const&)+0x28 at TREXNameServer.cpp:323 (libhdbns.so)
2: 0x00007f478d0c8385 in NameServer::TREXNameServer::startup()+0x1881 at TREXNameServer.cpp:1569 (libhdbns.so)
3: 0x0000556f6488a1f5 in TRexAPI::TREXIndexServer::startup()+0x5b1 at TREXIndexServer.cpp:3326 (hdbnameserver)
4: 0x0000556f648548bd in nlsui_main+0x17a9 at TrexService.cpp:578 (hdbnameserver)
5: 0x00007f476ac51786 in System::mainWrapper(int, char**, char**)+0x72 at IsInMain.cpp:332 (libhdbbasis.so)
6: 0x00007f476908434a in __libc_start_main+0xe6 (libc.so.6)
[26948]{-1}[-1/-1] 2021-06-08 12:33:03.356431 f NameServer TREXNameServer.cpp(03905) : Could not load HA/DR Provider -> stopping instance ...
[26948]{-1}[-1/-1] 2021-06-08 12:33:03.356700 f NameServer TREXNameServer.cpp(03918) : stopping topology thread
[26948]{-1}[-1/-1] 2021-06-08 12:33:03.356730 f NameServer TREXNameServer.cpp(03920) : got shutdown scope
[26948]{-1}[-1/-1] 2021-06-08 12:33:03.356734 f NameServer TREXNameServer.cpp(03924) : stopped topology thread
[26948]{-1}[-1/-1] 2021-06-08 12:33:03.356740 e Basis TREXNameServer.cpp(03934) : Process exited due to an error via explicit exit call with exit code 1 , no crash dump will be written
According to SAP documentation one should import dbapi
like @arbulu89 mentioned:
from hdbcli import dbapi
This PR https://github.com/SUSE/saphanabootstrap-formula/pull/129 in saphanabootstrap-formula
includes a fix and several other fixes.
There is also a test rpm available here:
Which can be used like this:
e.g.:
ha_sap_deployment_repo = "https://download.opensuse.org/repositories/home:/waldt:/branches:/network:/ha-clustering:/sap-deployments:/devel/SLE_15_SP2/"
or:
ha_sap_deployment_repo = "https://download.opensuse.org/repositories/home:/waldt:/branches:/network:/ha-clustering:/sap-deployments:/devel/SLE_15_SP3/"
@yeoldegrove Nice! This should come together with a docu change (as the old implementation was just following the best practices guide)
@pirat013 or @fmherschel, could have a look on this?
@yeoldegrove @arbulu89 Give me some time to review that on my installations. It would be an excellent improvement, if we do not longer need to install the dbapi manually as we had the need in the past.
@yeoldegrove @arbulu89 Yes we can use the new method to load the dbapi. Thanks for this suggestion. We should think about placing this Hook now in the SAPHanaSR package so customers not using the automation could also consume it. However the code (username and password) (what a bad situation) must be existing in clear text. I would prefer something like a secure store user key instead but I did not found a python binding to use the SAP secure user key storage.
@yeoldegrove @arbulu89 Yes we can use the new method to load the dbapi. Thanks for this suggestion. We should think about placing this Hook now in the SAPHanaSR package so customers not using the automation could also consume it. However the code (username and password) (what a bad situation) must be existing in clear text. I would prefer something like a secure store user key instead but I did not found a python binding to use the SAP secure user key storage.
@fmherschel The dbapi
has the option to use userkey
(hdbuserstore
). The key must be provided obviously.
We can open 2 additional tickets for the future.
SAPHanaSR
package@arbulu89 Ok I did a research in the past and asked SAP and they said that user keys was not implemented. So I missed that update. The explore of usage of the key I would like to see in the HA team of Markus Guertler. What do you think?
@arbulu89 Ok I did a research in the past and asked SAP and they said that user keys was not implemented. So I missed that update. The explore of usage of the key I would like to see in the HA team of Markus Guertler. What do you think?
Of course. Let us know if you need any assistance.
salt-deployment.log salt-result.log salt-predeployment.log salt-os-setup.log
Used cloud platform Azure
Used SLES4SAP version 15SP3
Used client machine OS SUSE Linux
Expected behaviour vs observed behaviour After deployment of Hana cluster, cost optimized scenario, secondary db does not start with message "HDB deamon not running". After investigating a bit I have found out that in file:
/hana/shared/PRD/exe/linuxx86_64/hdb/python_support/hdbcli/dbapi.py
there is a relative import causing the problemnameserver_vmhana02.30001.000.trc:[671]{-1}[-1/-1] 2021-05-18 10:54:02.469968 e ha_dr_provider PythonProxyImpl.cpp(00091) : import of srCostOptMemConfig failed: srCostOptMemConfig.py(39): Attempted relative import in non-package
Changing '.resultrow' to 'resultrow' fixed the issue. However, the python scripts belongs to SAP software and is specific to Hana version. In my test I used 2.33 and after checking against 2.52, the script and import looks different.
How to reproduce Specify the step by step process to reproduce the issue. This usually would look like something like this:
Used terraform.tfvars
Logs Logs uploaded:
Additional logs might be required to deepen the analysis on HANA or NETWEAVER installation. They will be asked specifically in case of need.