the config file option is not documented but exists.
Its also not mentioned in the pillar.example file where it at minimal should be shown

The "SAPHanaSR takeover blocker" feature described in https://www.suse.com/c/sap-hana-cockpit-with-suse-ha-integration-greatly-improves-data-integrity/ would be a good addition.

https://github.com/SUSE/saphanabootstrap-formula/blob/master/hana/packages.sls#L9

error

module.hana_node.null_resource.hana_node_provisioner[1] (remote-exec): [CRITICAL] Rendering SLS 'base:cluster.packages' failed: Problem running salt function in Jinja template: Zypper command failure: Check Zypper's logs.; line 11   module.hana_node.null_resource.hana_node_provisioner[1] (remote-exec): --- module.hana_node.null_resource.hana_node_provisioner[1] (remote-exec): [...] module.hana_node.null_resource.hana_node_provisioner[1] (remote-exec): {% if grains['os_family'] == 'Suse' %} module.hana_node.null_resource.hana_node_provisioner[1] (remote-exec): {% set pattern_available = salt['cmd.retcode']('zypper search patterns-ha-ha_sles') %} module.hana_node.null_resource.hana_node_provisioner[1] (remote-exec): {% endif %}   module.hana_node.null_resource.hana_node_provisioner[1] (remote-exec): {% if pattern_available == 0 %} module.hana_node.null_resource.hana_node_provisioner[1] (remote-exec): {% set repo = salt['pkg.info_available']('patterns-ha-ha_sles')['patterns-ha-ha_sles']['repository'] %} <====================== module.hana_node.null_resource.hana_node_provisioner[1] (remote-exec): patterns-ha-ha_sles: module.hana_node.null_resource.hana_node_provisioner[1] (remote-exec): pkg.installed: module.hana_node.null_resource.hana_node_provisioner[1] (remote-exec): - fromrepo: {{ repo }} module.hana_node.null_resource.hana_node_provisioner[1] (remote-exec): - retry: module.hana_node.null_resource.hana_node_provisioner[1] (remote-exec): attempts: 3 module.hana_node.null_resource.hana_node_provisioner[1] (remote-exec): [...] module.hana_node.null_resource.hana_node_provisioner[1] (remote-exec): ---
`

proposed solution

we should simplify this by just installing it without jinja functions.
(to do : https://github.com/uyuni-project/sumaform/blob/e9664647208498cf5b0b79695fa647c37a172dcf/salt/suse_manager_server/init.sls#L32)

this will fix also issue SUSE/ha-sap-terraform-deployments#140

Running the formula as single task showed, that i still can not connect/login to the database after the salt call is finished, as the database is still starting up.
It would be helpful to do something like a check if its accessible, before finishing the formula, especial in an fully automated workflow

In case the formula is run a second time, the whole code in hana/enable_primary.sls and hana/enable_secondary.sls is run a second time. This means a service interruption.

Something like 42245b9 could be an option to prevent this.
Ideally this is solved in salt-shaptools.

In Azure, I have noticed that the resource agents group composed by socat and ip address it's not properly colocated with SAP master.
Most probably due colocation value after we changed socat resource to azure-lb.
The official docs says 4000 of value, but we use 2000.
We should change the template, test and fix the issue.

sudo crm configure primitive rsc_nc_HN1_HDB03 azure-lb port=62503 \
  meta resource-stickiness=0

sudo crm configure group g_ip_HN1_HDB03 rsc_ip_HN1_HDB03 rsc_nc_HN1_HDB03

sudo crm configure colocation col_saphana_ip_HN1_HDB03 4000: g_ip_HN1_HDB03:Started \
  msl_SAPHana_HN1_HDB03:Master  

https://docs.microsoft.com/en-us/azure/virtual-machines/workloads/sap/sap-hana-high-availability

We're using this Salt formula in the Terraform deployments where we use SSH public keys. These passwords should be optional IMHO.

        root_user: 'root'
        root_password: 'linux'
        system_user_password: 'Qwerty1234'
        sapadm_password: 'Qwerty1234'

The pillar example file should show the key value pairs in a consistent state
Sometime its provided as comment only
but on other areas it shows e.g. two different methods as active values
e.g.
# Fetch HANA passwords from XML file
-> hdb_pwd_file: 'salt://passwords.xml'
# Or specify HANA system & sapadm users' passwords like below
^^^^^
-> system_user_password: 'Qwerty1234'
sapadm_password: 'Qwerty1234'

Starting with version 0.180 the SAPHanaSR-ScaleOut package supports SAP HANA scale-out multi-target system replication. That means you can connect a third HANA site by system replication to either of the two HANA sites which are managed by the SUSE HA cluster.

More Details can be found here:
https://www.suse.com/c/sap-hana-scale-out-upgrade-details/
https://www.suse.com/c/sap-hana-scale-out-multi-target-upgrade/

To enable this feature, a different hook script needs to be used:
/usr/share/SAPHanaSR-ScaleOut/SAPHanaSR.py
/usr/share/SAPHanaSR-ScaleOut/SAPHanaSrMultiTarget.py

So I was researching how to inject the gid and id for active directory integration and I found out that the best and elegant approach is to inject template files like https://github.com/SUSE/sapnwbootstrap-formula/blob/82f104952d812f4413920b8e38e63a95fc8984c5/netweaver/install_ascs.sls#L16

So having a template file, I would then from the deployment project modify those variable on the file adding if the ad present these vars. Then the formula here (hana) would just take the template file with the modified vars.

I have considered the pillar or other approaches/grains but I still considered that if we expose such files as template, it will be much more clear and easy to understand the whole machinery.

As alternative there is the grain approach where during the deployment, we set grains like ad_sapys_gid , ad_userid so and the formula here would take in case the exists.

On longerm, I think perhaps having a template file would simplify the install.

I was also thinking that the install function is to much "intelligent" or take to much responsability.

Imho we should split this call, in different phase:

• create conf file
• validate etc if needed
• install
• do post install if needed

Actually right now the install function is doing everything of this, which make difficult imho to have a fine grained debugging experience.

I will meanwhile explore the grain approach