suse / sapstartsrv-resourceagent Goto Github PK

Follow up item for: #10

Work in the monitor method.

1. Unify docstring
2. Reach 100% test coverage

On my test cluster I see interferences between SAPStartSrv and SAPInstance.
At the beginning I have all resources for ASCS00 on valuga11.
All resources for ERS10 are running on valuga12.

Now I call SAPInstance (with ERS10 parameters and action status) either manually or via cluster (crm resource cleanup rsc_sap_EN2_ERS10) on valuga11. After that sapstartsrv is running at valuga11 to. A later status action of rsc_sapsrv_EN2_ERS10 reports now running (even if it should not be running).

The reason is, that during the probe (status action) SAPInstance needs sapstartsrv (the SAP service) to run to check, if the SAP instance is running. This has multiple negative effects:

1. sapstartsrv for ERS10 is running multiple
2. file "available" now toggels status "Available"/"Unavailable"
3. file "sapstartsrv.log" gets overwritten and not longer contains the log of the running instance
4. file "sap_suse_cluster_connector.log" gets overwritten and not longer contains the log of the running instance

Fact 2 does also have consequences in customer monitoring tools (such as nagios)
Facts 3+4 are critical in SAP support situations, because the current files are not longer match to the running instance (e.g. on valuga12)

==> We might need to add a flag (parameter in SAPInstance not to start sapstartsrv for the simplified mount use-case) during probe (aka status).

When calling SAPStartSrv as probe (monitor interval 0) the RA returns 1 instead of 7.

The (internal) method _inititialize needs to be checked with various full-instance-names. Most of the tests are already using the split values of the full instance name like self.sid, self.instance_name and self.virtual_host.

In all those cases we are not checking the correct split of the full-instance-format SID_INSTANCE-NAME_VIRTUAL-HOST-NAME.
Important is that VIRTUAL-HOST-NAME are containing underscores ("_") so the number of field when splitting the string is >=3 and not always ==3.

Test cases could be e.g.

• full instance name is: HA1_ASCS10_suse01
• full instance name is: HA1_ERS20_suse02
• full instance name is: HA1_ERS20_suse02-cluster
• full instance name is: HA1_ERS20_suse02_cluster

This package requires python3-mock to build, and the Python packaging team are currently working towards removing that package since the lowest version of Python currently shipped in Tumbleweed provides mocking ability via unittest.mock. I see you've already changed the test code to support importing that instead. I'd suggest removing the BuildRequires for Factory only, or if that is not possible, guarding it with suse_version < 1500.