sap_swpm: add (pseudo)idempotency

[rob0d]

It seems that SWPM in an unattended mode happily overwrites already installed systems. We've just experienced this when we executed the full workflow on a partially installed environment and it reinstalled one of the instances (and remove all the configuration that was done to that instance).
I would like to suggest to make sap_swpm idempotent (dependant on settings).
The safest and simplest way to do this would be probably to check the existence of an instance profile. This can be done either generating the file name from the parameters that are set or by using code from sap_profile_update.

There would be three possible behaviours:

• default: as is now and just execute SWPM and overwrite any existing instances
• if instance already exists:
  • throw error
  • skip installation but continue

This can be achieved by having something like sap_swpm_check_if_instance_exists with options:

• false to keep the current behaviour (default)
• error to throw error
• ignore to ignore it and continue

I guess similar outcome can be achieved by splitting playbooks into smaller chunks and manually re-executing the failed bits if something goes wrong with one of the workflow steps, but that feels error prone and user dependent.

[marcelmamula]

@rob0d We will be implementing validations in sap_install roles some time in future to achieve this. @sean-freeman
There are already some ways we handle it during our tests and developments, which we can ten transfer to actual roles.

I am for example using this idempotency to detect and skip:

• hana install, hsr replication
• ascs, ers, pas, aap installed

Issue is of course caused by SWPM, which will blast home folder of sidadm user, then fail on subsequent steps after it finds kernel files already present.

[rob0d]

@marcelmamula that would be good. I can probably test some of it if it's available in the next month or so.
I think check in /usr/sap/sapservice and/or instance profile is probably the safest way of determining if something is (supposedly) installed without changing the state of anything.
And yes, the only way to prevent SWPM from updating the user profiles is not to start it at all.