Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parallelise daily jobs for different deployment types #859

Open
ryanemerson opened this issue Jun 24, 2024 · 0 comments
Open

Parallelise daily jobs for different deployment types #859

ryanemerson opened this issue Jun 24, 2024 · 0 comments

Comments

@ryanemerson
Copy link
Contributor

ryanemerson commented Jun 24, 2024

Description

Currently we create two ROSA clusters, then execute the Functional & Benchmarking tests against them for both Active/Passive, then Active/Active. The idea is that once the cluster has come up, it's then possible for members of the team to use these gh-keycloak-* clusters before they are torn down at the end of the working day in the us timezone.

However, it appears what often happens is that members of the team provision their own clusters for their work and the clusters sit idle most of the time.

My proposal is that we keep a daily scheduled run so that we can protect against regressions, however we delete the clusters as soon as the GH action run completes successfully. In the event of a test/setup failure, we should keep the cluster in order to allow a team member to investigate the root cause.

Benefits:

  • Reduced costs as the ROSA clusters will only be provisioned for the duration of the tests/benchmarks, not all day.
  • Increased parallelism. We can create clusters per deployment type, e.g. Active/Passive or Active/Active. This also provides increased isolation between the two environments, as we don't have to worry about state cleanup between deployment types.

Drawbacks:

  • Team members will always have to explicitly provision their own clusters for dev work

Discussion

However, it appears what often happens is that members of the team provision their own clusters for their work and the clusters sit idle most of the time.

Is this a valid observation and would team members be happy to modify their existing working patterns?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant