Collection: Add playbook for direct execution

[rhmk]

These are 2 playbooks which are added to the playbooks directory.

• sap_hana_preconfigure.yml can be called directly from the CLI and interactively asked for a minimum viable parameter set for preparing or checking a system for HANA installation. After the variable collection, it imports the next playbook with the collected parameters.
• sap_hana_preconfigure_exec.yml. This playbook can be called directly or imported into other playbooks with a prepared variable list. The host list is configurable so that the playbook can be used in generic workflows.
  Check the new README file in the playbooks directory for usage details of these roles.

[sean-freeman]

I'm inclined to reject the principle behind this PR:

• there is already /playbooks/sample-sap-hana-preconfigure.yml that covers this use case
• this appears to be (primarily focused on) using localhost as the end-users laptop and populate targets from comma-separated list of IP Addresses (into var _sap_systems)
• this has a two-tier Playbook structure, Playbook calling Playbook, and I feel this will confuse end-users
• this suggests to an end-user that the Playbook is "best practice" of some kind, but the underlying Ansible Roles have much more functionality - hence the reason why everything under /playbooks is prefixed as sample- because it is just the beginning of what can be achieved

If this is needed for some downstream purpose to provide Support or cleaner end-user "Just Run This" documentation/functionality, then I would suggest this code is instead added into the vendor-specific fork (aka. midstream).

[berndfinger]

If this is needed for some downstream purpose to provide Support or cleaner end-user "Just Run This" documentation/functionality, then I would suggest this code is instead added into the vendor-specific fork (aka. midstream).

Having playbooks which can be called directly after installing the collection (including upstream collections) has the following advantages:

• We can remove most of (if not all) examples from the role's README.md files, reducing their size. These sample playbooks in the README.md files can be replaced by an ansible-playbook command and the proper option for calling the interactive playbook.
• First time users will get a much easier and also faster quick start.
• It has the potential of increasing the adoption rate because there are fewer hurdles before getting a success when using the affected roles.
• By offering these playbook in the upstream version, we could also increase the collaboration by the community.

Because we will be leaving the existing sample playbooks with the dashes in their names untouched, existing functionality and scope will remain in place. See also #726 .

[rhmk]

@sean-freeman

1. As Bernd said - these playbooks cannot be called directly after installing the collection due to the dash in the name
2. the playbook adapts dynamically to localhost, all or any possible group defined inventory, so that the targets are not hardcoded as in sample- playbooks. This is a key reason to have them implemented from point of view.
3. I agree, that the two-tier playbook structure may look confusing, but it is an interactive "pre-playbook" that collects variables for easy entry, the second one is so generic that it can be used almost anywhere (e.g by the ansible playbooks), it just calls two roles and it works.

My intervention is indeed to move away from sample- mid-term and have callable playbooks that can be imported with a few parameters, to do what is needed.
I think we can discuss about the "parameter asking playbook" to have this in downstream only, but the _exec playbook is worth putting here.

[rhmk]

The PR is BTW a reaction to users who asked for a "directly usable" playbook

[berndfinger]

LGTM

[rhmk]

Removed the interactive part to provide a vendor-specific version of it and suggest to go forward with this PR. It makes the roles much easier consumable and reusable, e.g. in ansible-playbooks4sap

[berndfinger]

LGTM!