make sap_swpm (pseudo) idempotent #1005
Replies: 6 comments 7 replies
-
|
As we discussed together in PR and chat, we have wide range of combinations increasing complexity, but it can be alleviated by using combination matrix of different validations mentioned above. Idempotency is not always behaving same, so we have to distinguish: Detection and skip, versus proceeding with installation. PASS (proceed with sapinst):
SKIP
FAIL:
|
Beta Was this translation helpful? Give feedback.
-
|
I tried some more commands which might be useful for detecting running or installed instances:
Sample output:
Sample output: |
Beta Was this translation helpful? Give feedback.
-
|
I agree with the overall approach. I'd personally consider the approach required as less "idempotency of SWPM" and more "prevent overwrite of previous SWPM execution". It's OK to error, in my opinion. I would try to keep this more 'UNIXy' though. Less reliance on binary stdout, more reliance on files / state. For example: Then, we could have this in different strictness levels: # When SAP SWPM is run multiple times on the same host, other SAP software instantiations may exist and conflict
# In some cases SAP SWPM will not gracefully fail and may cause errors
# The SWPM rerun check provides pseudo-idempotency, by checking for existing directories, files and listening ports
sap_swpm_rerun_check: "strict" # strict, ports_only, profiles_onlyList of checks:
|
Beta Was this translation helpful? Give feedback.
-
Critical listening ports to check
|
Beta Was this translation helpful? Give feedback.
-
|
Gents, you both are pretty much spot on. Detecting if an instance is installed in order to achieve idempotency is unrealistic without a huge effort. The best we can do is to "guess" with a some level of certainty if what we are asking for is installed already or not. Then give the user choice of aborting or ignoring and hoping it will go well. The key thing here is that we can't rely just on saphostctrl. SWPM checks presence of instance profile in /sapmnt//profile and will happily damage .sapenv* files to do that and then fail saying instance is already installed. What's worse, SWPM behaviour differs depending on which component is it installing and what are the versions e.g.
In summary, we can't rely on SWPM to do the right thing, we should prevent it from running if we are not reasonably sure it's safe. I wrote this last year, but didn't take beyond testing the principle. - hosts: nwas_abap_pas, nwas_abap_aas
become: true
vars:
found_nw: 0
tasks:
- name: Ask saphostcontrol for a list of services
shell: "/usr/sap/hostctrl/exe/saphostctrl -function ListInstances | grep '{{ sap_system_sid }} - {{ instance_nr }}' |awk '{print $4,$6,$8}'"
#shell: "/usr/sap/hostctrl/exe/saphostctrl -function ListInstances | grep '{{ sap_system_sid }}' |awk '{print $4,$6,$8}'"
register: saphostctrl
ignore_errors: yes
changed_when: false
- name: Check if saphostcontrol hostname matches
set_fact:
saphostcontrolhostname: true
loop: "{{ saphostctrl.stdout_lines }}"
when: item.split()[2] == nbs_nwas_abap_pas_short
- name: Evaluate saphostcontrol hostname
set_fact:
found_nw: "{{ found_nw | int + 1 }}"
when:
- saphostcontrolhostname is defined
- saphostcontrolhostname == true
- name: Check sapservices contain the SID and Instance
shell: "grep -q 'SAP{{ sap_system_sid }}_{{ instance_nr }}' /usr/sap/sapservices"
register: sapservices
ignore_errors: yes
changed_when: false
- name: Evaluate if instance present in sapservices
set_fact:
found_nw: "{{ found_nw | int + 1 }}"
when: sapservices.rc == 0
- name: Check if the Instance profile exists
find:
paths: "/sapmnt/{{ sap_system_sid }}/profile/"
patterns: "{{ sap_system_sid }}_*{{ instance_nr }}_{{ instance_host }}"
register: sap_profiles
- name: Evaluate sap profiles
set_fact:
found_nw: "{{ found_nw | int + 1 }}"
when: sap_profiles.matched > 0
- name: Finished
debug:
var: found_nw |
Beta Was this translation helpful? Give feedback.
-
|
We also need to add directory check, because system might not be detected as previous run failed, but filesystem contains folders that will crash SWPM. ERROR 2025-05-15 11:51:09.669 (root/sapinst) (startInstallation) [CSiStepExecute.cpp:1105] id=controller.stepExecuted errno=FCO-00011 CSiStepExecute::execute()
The step check_dir_ct_run with step key |NW_ABAP_ASCS|ind|ind|ind|ind|0|0|nw_check_dir_ct_run|ind|ind|ind|ind|dirctrun|0|check_dir_ct_run was executed with status ERROR (Last error reported by the step: <p style="margin-top: 0"> DIR_CT_RUN=/usr/sap/E00/SYS/exe/uc/linuxx86_64 is not empty. DETAILS: An empty directory is required for a new SAP system installation. SOLUTION: Clean up the directory to be able to proceed. </p>). |
Beta Was this translation helpful? Give feedback.
-
|
We use like a linuxlab status file on the os that will be checked before execution and updated after successfull execution. So if the swpm ends successfully we trust the system to be installed correctly. The status file contains a status for pending and for done. Here an example of a status file after installation: To make our code idempotent we check what products have a done status. In the ansible --check fase we inform the user which products needs to be installed not having the done status. For me this is a simple solution that allows me to run the code over and over again. There are "risk" when checking on services or ports or profiles. For example installations can break in the last steps changing ddic passwords or running some abap reports. The playbook will then crash and if you would run it again it would say everything was fine (but it wasn't). Maybe it's some additional thoughts that may be useful. |
Beta Was this translation helpful? Give feedback.
-
|
@sjoerd-lubbers I have used status file for automation re-executions and capturing their results (for IQOQ and test results) in past, but it has limitations:
It is great tool to be used when you have controlled environment, where everyone knows that is certain file on OS level that is important and nobody touches it unless needed. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with @marcelmamula entirely here; a clear/detailed reasoning of my gut reaction |
Beta Was this translation helpful? Give feedback.
-
|
As we are talking Ansible here, a reasonable place could be /etc/ansible/facts.d/sap. |
Beta Was this translation helpful? Give feedback.
-
|
Another possibility is that you run the swpm role in a block statement, and if it fails (rescue), do a complete cleanup and rerun the swpm role |
Beta Was this translation helpful? Give feedback.
-
|
I am not 100% keen on a I can imagine this situation....:
I hesitate to use these examples (given the Please see:
|
Beta Was this translation helpful? Give feedback.
-
|
I have implemented idempotency for
Important
Workflow proposalvars/main.yml
Option: We can also add Detection task fileWorkflow for detection in block with
Pre-install
Main
Post-install
SAP System is installed and running.
...
{% if __sap_swpm_fact_is_installed %}
Existing SAP System and Instance was detected and installation steps were skipped.
This role is not validating if existing system is of expected product.
{% endif}
{% if sap_swpm_setup_firewall %}
Firewall is enabled and SAP ports are open.
{% endif %} |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
#730 suggested to make sap_swpm (pseudo idempotent), and #1003 was a first attempt to do so.
The discussion in the PR revealed that there is more to consider.
I think we need to take into account the following:
sap_swpm_product_catalog_idNW_DI:S4HANA2023.FNDN.HDB.PDsap_swpm_product_catalog_idNW_ABAP_OneHost:S4HANA2023.FNDN.HDB.ABAPSAP instance status on the destination system
sapcontrol -nr <number> -function GetSystemInstanceListas the<sidadm>user for one of the desired SAP instances and get the SAP instance types from the last column. If the installed SAP instance types and numbers are matching the desired ones -> Role will report that the desired SAP instance(s) is/are already installedSAP instance detection method:
/usr/sap/hostctrl/exe/saphostctrlexists? Run/usr/sap/hostctrl/exe/saphostctrl -function ListInstancesand take its output for determining the installed SAP systems./usr/sap/hostctrl/exe/saphostctrl -function ListInstancescontains the desired instance numbers, we can assume that these instances are installed, so we can immediately fail if these belong to another SAP system (case 2.i.). If they belong to the same SAP system ID (case 2.ii.), we need to runsapcontrolas described above, for determining the SAP instance type and can then decide if the desired instance(s) is/are installed or not./usr/sap/hostctrl/exe/saphostctrl -function ListInstancesdoes not contain the desired instance numbers, there might also be a communication error and one or more of the desired instances might still be running or installed. In this case, we perform further checking on the OS level:<SID>exists -> set marker 1<SID>exists -> set marker 2<sidadm>user exists -> set marker 3<SID>/profile/<SID>*<number>_<hostname>exists for all desired SAP instances -> set marker 4Thoughts?
Beta Was this translation helpful? Give feedback.
All reactions