Allow for more than one deployment per test under cloud-qa #173
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
3 tasks
lsierant
force-pushed
the
lsierant/pytest-refactor
branch
from
043f6e7 to
93baf39
Compare
lsierant
force-pushed
the
lsierant/multi-cloud-qa
branch
from
4ba55b0 to
8515b05
Compare
lsierant
force-pushed
the
lsierant/pytest-refactor
branch
from
93baf39 to
35c3435
Compare
lsierant
force-pushed
the
lsierant/multi-cloud-qa
branch
from
8515b05 to
5ee79b4
Compare
|
evergreen retry |
lsierant
added a commit
that referenced
this pull request
Jun 4, 2025
# Summary This PR contains no functional changes - only moving functions around. It's extracting common bits imported from different places to their own files which resolves *some* cyclic dependencies in the code. It's by no means a complete refactor, it's an extracted refactor from the followup change (#173) which triggered cyclic dependencies in the first place. ## Proof of Work [Green EVG](https://spruce.mongodb.com/version/683fe9d44e8b7f0007877a9e/tasks?sorts=STATUS%3AASC%3BBASE_STATUS%3ADESC) ## Checklist - [ ] Have you linked a jira ticket and/or is the ticket in the title? - [ ] Have you checked whether your jira ticket required DOCSP changes? - [ ] Have you checked for release_note changes? ## Reminder (Please remove this when merging) - Please try to Approve or Reject Changes the PR, keep PRs in review as short as possible - Our Short Guide for PRs: [Link](https://docs.google.com/document/d/1T93KUtdvONq43vfTfUt8l92uo4e4SEEvFbIEKOxGr44/edit?tab=t.0) - Remember the following Communication Standards - use comment prefixes for clarity: * **blocking**: Must be addressed before approval. * **follow-up**: Can be addressed in a later PR or ticket. * **q**: Clarifying question. * **nit**: Non-blocking suggestions. * **note**: Side-note, non-actionable. Example: Praise * --> no prefix is considered a question
lsierant
force-pushed
the
lsierant/multi-cloud-qa
branch
from
5ee79b4 to
973fbda
Compare
lsierant
force-pushed
the
lsierant/multi-cloud-qa
branch
from
5bd8491 to
94a69a9
Compare
|
evergreen refresh |
|
Try to use this in docker/mongodb-kubernetes-tests/tests/authentication/mongodb_custom_roles.py when #54 is merged |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This patch allows to deploy more than one database managed by cloud-qa in a single e2e test.
Currently it's only possible under Ops Manager tests which deploys it in the same test.
How does it work for OM?
Multiple mdb resources under OM are possible thanks to resource.confgure() function, which requires to pass MongoDBOpsManager resource. It creates -project config map and credentials secret by using api keys that are available because there is an OM instance deployed in the same test.
How it was for cloud-qa tests?
Our tests were able to use only one "my-project" config map and credentials, which is created before the test pod is scheduled (configure_operator.sh). It contains fixed project name, which equals to the current namespace (a random string in CI). Reusing this config map leads to attempting to deploy mdb resource in the same cloud-qa project, which then the operator rejects.
What this PR changes for cloud-qa tests?
We hook into configure function allowing for passing None as ops manager resource. In this case we clone
my-projectconfig map and overwrite projectId to '{namespace}-{resourceName}'. The operator will then create a new cloud-qa project with that name allowing for running multiple cloud-qa-managed resources in one test.Proof of Work
TBD as CI has a fatal failure.
Checklist
Reminder (Please remove this when merging)