-
Notifications
You must be signed in to change notification settings - Fork 284
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
Improve CloudStack E2E template selection logic #5923
Conversation
a736796
to
822bf6e
Compare
Codecov Report
@@ Coverage Diff @@
## main #5923 +/- ##
==========================================
+ Coverage 73.63% 73.64% +0.01%
==========================================
Files 452 452
Lines 37992 38016 +24
==========================================
+ Hits 27974 27998 +24
+ Misses 8395 8394 -1
- Partials 1623 1624 +1
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking great!
3c08a3d
to
4f1c7c1
Compare
/test eks-anywhere-presubmit |
Refactor vSphere and CloudStack template name code to fit for all the providers
4f1c7c1
to
2c9c7d8
Compare
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED Approval requirements bypassed by manually added approval. This pull-request has been approved by: The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Refactor vSphere and CloudStack template name code to fit for all the providers
Description of changes:
For CloudStack e2e tests we get the template names from the secret value. When we change eks-d version, template names get out of sync which makes e2e test failure until we change the template name in the secret.
To avoid this, this PR includes a logic to select the right template from the test runner itself and by not depending on the secret value. It looks for template name in below order,
Look for explicit configuration through an env var: "T_CLOUDSTACK_TEMPLATE_{osFamily}_{eks-d version}" eg. T_CLOUDSTACK_TEMPLATE_REDHAT_KUBERNETES_1_23_EKS_22. This should be used for explicit configuration, mostly in local development for overrides.
If not present, look for a template if the default templates: "{eks-d version}-{osFamily}" eg. kubernetes-1-23-eks-22-redhat. This is what should be used most of the time in CI, the explicit configuration is not present but the right template has already been imported to cloudstack.
If the template doesn't exist, default to the value of the default template env vars: eg. "T_CLOUDSTACK_TEMPLATE_REDHAT_1_23". This is a catch all condition. Mostly for edge cases where the bundle has been updated with a new eks-d version, but the the new template hasn't been imported yet. It also preserves backwards compatibility.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.