Add GitHub workflows to create and delete a shared ROSA cluster

[stianst]

I've tested this on my fork:

• Create cluster: https://github.com/stianst/keycloak-benchmark/actions/runs/5088576833/jobs/9145155404
• Delete cluster: https://github.com/stianst/keycloak-benchmark/actions/runs/5088530163/jobs/9145048362

[mhajas]

Makes sense to me. Then we can add the cluster name as the parameter for the benchmark run.

[kami619]

@stianst

In the referenced run : https://github.com/stianst/keycloak-benchmark/actions/runs/5088576833/jobs/9145155404

Login failed (401 Unauthorized)
Verify you have provided the correct credentials.
2023-05-26T08:39:44+00:00
WARNING: Using insecure TLS client config. Setting this option is not supported!

I see that it failed to authenticate a bunch of times before it succeeded., which is unlike the behavior we saw on local runs., is this expected ?

[kami619]

also we are generating some debug logs for each custer create and delete using rosa scripts, do we want to retrieve them somehow for debugging the errors on aws or otherwise ? if you think, that should be done in a future PR, thats OK with me too. @stianst

[stianst]

@stianst

In the referenced run : https://github.com/stianst/keycloak-benchmark/actions/runs/5088576833/jobs/9145155404

Login failed (401 Unauthorized)
Verify you have provided the correct credentials.
2023-05-26T08:39:44+00:00
WARNING: Using insecure TLS client config. Setting this option is not supported!

I see that it failed to authenticate a bunch of times before it succeeded., which is unlike the behavior we saw on local runs., is this expected ?

I changed it to not wait for 1m, but instead just keep trying every 10 seconds, so that'll be the reason for a few more failures there. I think it is better to have it fail a few times, then waiting for too long?

[stianst]

I'd say let's add it later. Probably just grab the logs and store as artifacts if it fails to deploy. Don't think we need any logs if it is successful? Related to this is we could probably also make sure everything is cleaned-up if something fails.

[kami619]

Agreed on log management to be taken care later, fine for it fail fast, than have to wait. This PR looks good to be merged, if there are no other comments