search

sap-linuxlab / community.sap_install

Automation for SAP - Collection of Ansible Roles for various SAP software installation
Apache License 2.0
57 stars 57 forks source link

sap_general_preconfigure: using sapconf instead of saptune #499

Closed itdose2023 closed 1 month ago

itdose2023 commented 1 year ago

saptune is only part of "SLES for SAP Application" but not included in "SLES". But with "SLES" sapconf can be used to setup SAP related environements.
Therefore, we will need to distinguish in SuSE Linux if sapconf or saptune is to be used. see https://me.sap.com/notes/1275776

Request is, to add another Variable like "run_saptune={true|false}" and "run_sapconf={true|false}" to distinghuish within installation- playbooks / roles.

sean-freeman commented 1 year ago

@scmschmidt I defer this decision to you. My understanding was sapconf had effectively no further developments by any SAP Technology Partner in the SAP LinuxLab, only patches.

itdose2023 commented 1 year ago

Hello,

thanks for the feedback! I added my SAP Colleague Wolfgang to this mail and added Markus here – we’re in contact for this change.

Regarding saptune/sapconf: SLES is not delivered with saptune – but sapconf. SuSE provides saptune only with SLES for SAP Applications- Versions. (https://blogs.sap.com/2019/06/25/sapconf-versus-saptune-in-more-detail/ and https://blogs.sap.com/2020/08/03/sapconf-5-what-has-changed/) For most VM’s we use SLES – that’s why we still stick on sapconf. Honestly – I’m not aware, if sapconf is depreciated? Will discuss this again in my Team.

Regards, Bruno

scmschmidt commented 1 year ago

As said by Bruno, sapconf is shipped with SLES (also SLES for SAP) and saptune in SLES for SAP. Sapconf gets developed further, but there is little to no change in the last years. The reason is that sapconf is a small tool to tune only the parameters where defaults most certainly hurt SAP workload. As long nothing new turns up, sapconf will stay as it is, but I can understand that it must look like it only gets bugfixes.

I think the request makes sense. Depending on the OS and the choice of the customer both tools are valid tuning choices.

sean-freeman commented 1 year ago

For reference purposes, high-level SNote 2369910 - SAP Software on Linux: General information refers to:

I would need to validate further (no time to do that), but off-hand I believe all SAP Cloud IaaS Certified vendors must use SLES4SAP or RHEL4SAP (excluding other variants available on Cloud IaaS like Windows Server or IBM AIX) in their offerings to customers, and the SAP Support is void if these are not used.

If we proceed to update the Ansible Collection to permit SLES and RHEL only, I could see significant scope creep, customer confusion and unknowingly preparing SAP System hosts that would never be supportable by SAP after any automation code has completed.

I'd suggest this is brought before the SLL-OSI Governance Board for discussion on the Ansible Collections reasonable restrictions, limitations and scope. This would be a joint decision required - @berndfinger please be aware of this GH Issue.

marcelmamula commented 10 months ago

https://github.com/sap-linuxlab/community.sap_install/pull/597 Created to fix issue created by this 499 issue.

sean-freeman commented 10 months ago

@marcelmamula What issues? This code was already tested?

marcelmamula commented 10 months ago

@marcelmamula What issues? This code was already tested?

I saw your merge so I pulled changes and run it. Both preconfigure step for SLES fail because there is block and command on same indent. So I fixed this issue, fixed lint errors and implemented re-ordering of saptune steps from other issue.

- name: Ensure saptune solution is applied
  ansible.builtin.command: "saptune solution apply {{ sap_hana_preconfigure_saptune_solution }}"
  #changed_when: true
  when:
    - __sap_hana_preconfigure_run_saptune
    - __sap_hana_preconfigure_register_saptune_verify.rc != 0
  block:

    - name: Ensure solution was successful

netweaver preconfigure is also expecting variable that was not added into defaults, so it is undefined on SLES_SAP systems so I had to fix that too.

Blocks were also re-arranged for simplicity and easier to spot conditionals.

sean-freeman commented 10 months ago

@marcelmamula Yeah just seen them - should have been detected when the ansible-lint ran upon my PR insertion. Good catch.

sean-freeman commented 9 months ago

@itdose2023 This work was completed in PR 597. Can this GH Issue be closed, and your synced repo (running weekly GH Actions) removed?

Wabri commented 9 months ago

Yes, I think so!