Hardcoded timeout for call of getParameter.py to get operation mode? about saphanasr

[fmherschel]

The first reason was, that getParamater.py should always answer very fast. Do you have a realistic situation, where getParameter.py did not answer in time? What might be the reason for this? A hanging NFS share? I did not had reviewed that now on code level. My guess is that other then for systemReplicationStatus.py where we have a hard argument to stay with the short timeout, we might change that for the getParameter.py. But we also should take into account that hanging resources could not all be addressed by the SAPHanaSR* resource agents. In special the classic SAPHanaSR resource agents are not independent from the cluster system environment.
Just my first 2ct.

[fdanapfel]

I don't have an actual situation where getParameter.py did not answer in time, I was just asked by some colleagues why there is a hardcoded timeout for the call of getParameter.py in this specific case, whereas for other calls of getParameter.py the configurable timeout is used in the resource agents.

[fmherschel]

I just have reviewed: https://github.com/SUSE/SAPHanaSR/blob/maintenance-classic/ra/SAPHana#L2664
This is "only" the operation mode if the SR. It needs to be only aquired once* before a register of a former primary is done. So we selected a shorter timeout to prevent to long RA runtimes by adding long timeouts in sequence.
But maybe we should implement the fallback. If getting log-mode is timing-out the function should keep the old value of a query done before.

*) We query the status more than once to get updates, if something would change during the cluster runtime.