Add playbook for openqa pt install

[BillAnastasiadis]

This pr adds

• one playbook to download and install a ptf in the nodes, both manually (via the suse ptf download directory) and on openqa (via azure storage)

• one playbook for specific tasks needed by the azure fence agents

• Related ticket: https://jira.suse.com/browse/TEAM-9453

• Verification run: https://openqa.suse.de/tests/14729087 (failure later and unrelated)
  https://openqa.suse.de/tests/14744852 (newest)
  https://openqa.suse.de/tests/14744947 (without ptf)

[mpagot]

we can avoid this "trick" (that create hidden dependency of path used in hana_media.yaml and playbooks/sap-hana-download-media.yaml) and just force the user to provide the path in a second variable just for this playbook

ptf_installation.yaml -e ptf_container="aaa/bbb/ptf" -e ptf_files="aaa.rpm,bbb.rpm"

or with the path in each file element

ptf_installation.yaml  -e ptf_files="aaa/bbb/ptf/aaa.rpm,aaa/bbb/ptf/bbb.rpm"

[BillAnastasiadis]

Yes, that can be done - but is it really needed? This code just grabs the first part, which is always bound to be the name of the top-level container, which isn't going to change (or, if it changes, it will change for everything). Let's discuss in slack

[mpagot]

We can decide to use a dedicated container for PTF.
Maybe one with a subfolder for each PTF

[mpagot]

why we like them to be parametric?
why hardcoding value directly in Download PTF files with SAS token is not enough?

[mpagot]

LGTM

My only concern is that it come out with a complicated API (no idea if /how we can improve it)

• url_timeout, url_retries_cnt, url_retries_delay can be configured from the external but has default. There's no validatio nof values if configured from the external.
• sas_token is optional. Its presence is one of the variables checked to decide which download task to use. Name overlap with the one used in hana_media.yaml but they are two different variables (even if for the moment, due to what we currently have in Azure, token is the same). It cold be an idea to rename it to ptf_sas_token and just externally (openQA) use same token used for HANA install?
• ptf_files is mandatory if sas_token is defined. It has to have a special format like comma separated list of filename (or is filename + some path?). Its presence is not checked or validated before to start using it
• container, storage are mandatory if sas_token is defined. They have to be strings. Their presence are not checked or validated before to start using them
• ptf_user, ptf_password, ptf_url are optional and used to select a specific download task. The first two are string, password is a secret, ptf_url is an url. None are validated.

[BillAnastasiadis]

LGTM

My only concern is that it come out with a complicated API (no idea if /how we can improve it)

• url_timeout, url_retries_cnt, url_retries_delay can be configured from the external but has default. There's no validatio nof values if configured from the external.
• sas_token is optional. Its presence is one of the variables checked to decide which download task to use. Name overlap with the one used in hana_media.yaml but they are two different variables (even if for the moment, due to what we currently have in Azure, token is the same). It cold be an idea to rename it to ptf_sas_token and just externally (openQA) use same token used for HANA install?
• ptf_files is mandatory if sas_token is defined. It has to have a special format like comma separated list of filename (or is filename + some path?). Its presence is not checked or validated before to start using it
• container, storage are mandatory if sas_token is defined. They have to be strings. Their presence are not checked or validated before to start using them
• ptf_user, ptf_password, ptf_url are optional and used to select a specific download task. The first two are string, password is a secret, ptf_url is an url. None are validated.

• this was inherited from sap_download-hana-media.yaml, which uses them in the Download HANA media with SAS token task. Since the sas-token method of downloading in my playbook is basically copied from that function, I used the same args and values.
• sas_token does not have the same name as in sap_download-hana-media.yaml: there, it's az_sas_token, while I renamed it to simply sas_token
• I can validate it, should I try? Or should we let the task fail and the reviewer review it?
• Similar question as above
• Similar as above

[lpalovsky]

LGTM