sap_general_preconfigure: The strict DNS check enforcement of PR 765 causes failures in certain cloud environments

[berndfinger]

So we better make the DNS check optional by default and introduce a new role parameter for only failing the role if desired.

[berndfinger]

Note: The change was introduced by #765.

[berndfinger]

Also the task names which contain role variables do not always show the correct content (depending on how the role was executed, e.g. when being called with include_role.

[sean-freeman]

This issue can occur on different platforms, and may cause frustration for the end-user if it is outside of their control.

For Example, end user may only have access to DNS A Records in 1 DNS Zone provided via MS Azure Private DNS and "Reverse DNS (PTR) records are not stored in a forward private DNS zone. Reverse DNS records are stored in a reverse DNS (in-addr.arpa) zone.". Source: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances

Making this optional will avoid a breaking change and ensure end users that want to be strict, can do so, and those who need more flexibility will see an error message but not stop the Ansible Role from continuing.

[rob0d]

Currently I don't have access to any cloud environment where I could test it. I am not sure if GCP and AWS behave in the same way as Azure with regards to the PTR records. It seems that Azure behaviour is on the verge of non-compliance with RFC1912 section 2.1, but I guess it is understandable why they do that.
Are you able to confirm if Azure is returning two PTR records and one if them is correct? Also is there anyone who can check how GCP and AWS behave?