WIP / PoC: Native multi-cluster openshift-applier run

[oybed]

What does this PR do?

Proposed example of a multi-cluster openshift-applier run. Would like to discuss this approach.

Note that there's potentially one shortcoming with this approach - i.e.: using kubeconfig with pre/post steps. The pre/post step roles will need to be made kubeconfig aware (unless we find a way to apply it globally on a per-host basis).

How should this be tested?

N/A - proposal up for discussion

Is there a relevant Issue open for this?

N/A - proposal up for discussion

Who would you like to review this?

cc: @redhat-cop/openshift-applier

[mike4263]

@oybed Looks good

[etsauer]

@oybed so, with the changes to the role, would that require any changes to existing inventories?

[oybed]

@etsauer first off, I just updated the title of this PR with WIP to indicate that this isn't something to merge as-is - at least not yet.

This PR is a proposal for how we can handle multi-clusters. The goal would be to not have to change existing inventories, and that should be doable. However, we need to come up with the "improved story" around how we manage OpenShift login sessions, so the solution should be:

1. Should be able to use existing inventories as-is (including providing a valid session at runtime)
2. Provide login info for handling login/session at runtime
3. Handle multiple clusters (each with separate sessions - either existing of new per 1 & 2 above).

[etsauer]

@oybed

[etsauer]

This will cause pre-existing applier inventories to fail if not set. I would suggest two things:

• first, make this optional. i.e. skip it if these variables are not set
• set a default value for openshift_insecure so that it is not required.

[oybed]

@etsauer yes, there are multiple things that need to be polished before this can be merged. Main intent for the PR was to have a discussion starting point around the concept (and if it's worth spending time on it)

[etsauer]

@oybed understood, and I like the approach.

[oybed]

Based on the feedback so far, it seems that this approach is worth the effort, so I'll spend some time on finalizing the approach and polish the implementation.

[etsauer]

Another use case I would like to see work:

cluster1.yml:

openshift_login_url: https://console.cluster1.example.com
...

cluster2.yml:

openshift_login_url: https://console.cluster2.example.com

Run:

oc login -u bob https://console.cluster1.example.com
Password:
oc login -u bob https://console.cluster2.example.com
Password:
ansible-playbook .... -e openshift_user=bob

[oybed]

@etsauer are you ok if the prompts are part of the ansible run? Basically something similar to this:
https://github.com/redhat-cop/infra-ansible/blob/master/playbooks/prep.yml