Changed the order of CreateOrUpdate functions #1623
Merged
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
lsierant
changed the title
lsierant
requested review from
mircea-cosbuc,
slaskawi,
nammn,
Julien-Ben,
MaciejKaras,
lucian-tosa and
fealebenpae
as code owners
mircea-cosbuc
approved these changes
Sep 28, 2024
Julien-Ben
approved these changes
Sep 30, 2024
MaciejKaras
approved these changes
Sep 30, 2024
lucian-tosa
approved these changes
Sep 30, 2024
nammn
reviewed
Sep 30, 2024
| if apiErrors.IsNotFound(err) { | ||
| return getUpdateCreator.CreateConfigMap(ctx, cm) | ||
| } else { |
There was a problem hiding this comment.
i am a bit late to the party but we could have saved the else and just return, right?
There was a problem hiding this comment.
When I see such if/else I always wonder if I should leave a comment
Should we try to be consistent in the whole codebase about that ?
We use both currently
There was a problem hiding this comment.
we should add a linter for that and we should be fine. Problem: mco doesn't have that linter configured
fealebenpae
pushed a commit
to mongodb/mongodb-kubernetes
that referenced
this pull request
Apr 10, 2025
This patch contains a number of improvements tried in order to deflake e2e tests. Overally result is quite successful: [100% green EVG](https://spruce.mongodb.com/version/66f81d4d24506900071e3563/tasks?sorts=STATUS%3AASC%3BBASE_STATUS%3ADESC) and progress with [flakes](https://ui.honeycomb.io/mongodb-4b/environments/production/result/8p2zFkfJ2Pz) Changes: - deleting kind clusters before creating kind clusters; controllable by new DELETE_KIND_NETWORK env, which is true only in EVG run (set in evg-private-context only). This one is actually of a dubious value as we're doing docker prune in teardown already. But it's useful also for our own evg hosts as we've never cleared docker network once created. - setting the subnet for docker network explicitly to 172.18.0.0/16. We hardcode usage of this subnet locally, and docker network in evg started to assign subnets on different IPs. That's why sometimes our "interconnected" tests were passing - when docker network created in evg got lucky subnet (172.18)! - added ttl and refresh to coredns config map - cannot harm, not sure if helps - changed the order of CreateOrUpdate to always update first and if 404 then create. Previously we had get first which was susceptible to not refreshed informers and CreateOrUpdate was going directly to Create which was failing. Details in [PR in MCO](mongodb/mongodb-kubernetes-operator#1623)
fealebenpae
pushed a commit
to mongodb/mongodb-kubernetes
that referenced
this pull request
Apr 21, 2025
This patch contains a number of improvements tried in order to deflake e2e tests. Overally result is quite successful: [100% green EVG](https://spruce.mongodb.com/version/66f81d4d24506900071e3563/tasks?sorts=STATUS%3AASC%3BBASE_STATUS%3ADESC) and progress with [flakes](REDACTED) Changes: - deleting kind clusters before creating kind clusters; controllable by new DELETE_KIND_NETWORK env, which is true only in EVG run (set in evg-private-context only). This one is actually of a dubious value as we're doing docker prune in teardown already. But it's useful also for our own evg hosts as we've never cleared docker network once created. - setting the subnet for docker network explicitly to 172.18.0.0/16. We hardcode usage of this subnet locally, and docker network in evg started to assign subnets on different IPs. That's why sometimes our "interconnected" tests were passing - when docker network created in evg got lucky subnet (172.18)! - added ttl and refresh to coredns config map - cannot harm, not sure if helps - changed the order of CreateOrUpdate to always update first and if 404 then create. Previously we had get first which was susceptible to not refreshed informers and CreateOrUpdate was going directly to Create which was failing. Details in [PR in MCO](mongodb/mongodb-kubernetes-operator#1623)
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.
This PR changes the way we do
CreateOrUpdatefunctions.It was: Get the Update if exists else Create.
For some cases after the resource was created in the same reconcile event, another execution will again hit into Create case as the informer caches weren't yet refreshed. And that resulted in errors.