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

Support a single change stream to listen to all op log events #2540

Open
wants to merge 9 commits into
base: development/8.6
Choose a base branch
from

Conversation

williamlardier
Copy link
Contributor

@williamlardier williamlardier commented Sep 13, 2024

  • Listen to all collections but the special ones and the mpu shadow buckets.
  • Introduce pipeline factories, that will handle all the logic related to pipelines, to simplify other files.
  • Introduce the UniqueConnector strategy, to handle the new type of pipeline and allocations in a standard way.
  • Update the handling of old connector: the strategies' & their pipeline factory are used to know if an old bucket should be removed, or kept. This means, if we switch between wildcard and non-wildcard pipelines, we ensure a given bucket is never being listened to more than once.

Issue: BB-602

Copy link

codecov bot commented Sep 13, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 69.62%. Comparing base (0a32e66) to head (336ab09).

Additional details and impacted files

Impacted file tree graph

Files with missing lines Coverage Δ
extensions/oplogPopulator/OplogPopulator.js 88.97% <100.00%> (+0.26%) ⬆️
...ns/oplogPopulator/OplogPopulatorConfigValidator.js 66.66% <ø> (ø)
...Populator/allocationStrategy/AllocationStrategy.js 100.00% <100.00%> (+16.66%) ⬆️
...lator/allocationStrategy/RetainBucketsDecorator.js 100.00% <100.00%> (ø)
...logPopulator/allocationStrategy/UniqueConnector.js 100.00% <100.00%> (ø)
extensions/oplogPopulator/constants.js 100.00% <ø> (ø)
extensions/oplogPopulator/modules/Connector.js 85.10% <100.00%> (-0.16%) ⬇️
...nsions/oplogPopulator/modules/ConnectorsManager.js 93.98% <100.00%> (+0.04%) ⬆️
...pulator/pipeline/MultipleBucketsPipelineFactory.js 100.00% <100.00%> (ø)
...ensions/oplogPopulator/pipeline/PipelineFactory.js 100.00% <100.00%> (ø)
... and 1 more

... and 8 files with indirect coverage changes

Components Coverage Δ
Bucket Notification 66.66% <ø> (ø)
Core Library 73.98% <ø> (-0.04%) ⬇️
Ingestion 69.24% <ø> (+0.53%) ⬆️
Lifecycle 75.00% <ø> (ø)
Oplog Populator 84.66% <100.00%> (+1.71%) ⬆️
Replication 57.42% <ø> (ø)
Bucket Scanner 85.60% <ø> (-0.16%) ⬇️
@@                 Coverage Diff                 @@
##           development/8.6    #2540      +/-   ##
===================================================
+ Coverage            69.37%   69.62%   +0.24%     
===================================================
  Files                  194      198       +4     
  Lines                12791    12916     +125     
===================================================
+ Hits                  8874     8993     +119     
- Misses                3907     3913       +6     
  Partials                10       10              
Flag Coverage Δ
api:retry 9.62% <0.00%> (-0.05%) ⬇️
api:routes 9.52% <0.00%> (-0.04%) ⬇️
bucket-scanner 85.60% <ø> (-0.16%) ⬇️
ingestion 12.47% <0.00%> (-0.01%) ⬇️
lib 7.52% <0.00%> (-0.04%) ⬇️
lifecycle 19.35% <0.00%> (-0.09%) ⬇️
notification 0.88% <0.00%> (-0.01%) ⬇️
replication 18.89% <0.00%> (-0.08%) ⬇️
unit 43.38% <100.00%> (+0.24%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Copy link
Contributor

@francoisferrand francoisferrand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this is the right approach... This change is trying to fit this single-change-stream approach in the existing code flow (computing which connector should handle the bucket, etc...), while in this approach there is mostly nothing to do : it is really about setting up one connector on system startup, and just call it a day...

(would still need to keep the reconcile loop, to ensure we restart failed connectors, though... and we may need to consider what to do when changing the overall mode)

I don't know if we should change or how, but I think we really need to dig a bit deeper here.

@williamlardier
Copy link
Contributor Author

williamlardier commented Sep 16, 2024

@francoisferrand shouldn't we also handle "old" connectors on startup? We can detect them and close them to recreate a single connector, or leave them untouched and handle any new connector in a single one. If we only create one connector, I'm not sure this will work for existing deployments.

Edit: as discussed the current code should cover our tests needs. If a customer needs this approach, we will handle it manually, so no need to handle old connectors here.

@williamlardier williamlardier force-pushed the improvement/BB-601-logic branch 16 times, most recently from 7396ddc to a1e9895 Compare September 19, 2024 10:01
Base automatically changed from improvement/BB-601-logic to development/8.6 September 19, 2024 11:51
@bert-e
Copy link
Contributor

bert-e commented Sep 19, 2024

Hello williamlardier,

My role is to assist you with the merge of this
pull request. Please type @bert-e help to get information
on this process, or consult the user documentation.

Available options
name description privileged authored
/after_pull_request Wait for the given pull request id to be merged before continuing with the current one.
/bypass_author_approval Bypass the pull request author's approval
/bypass_build_status Bypass the build and test status
/bypass_commit_size Bypass the check on the size of the changeset TBA
/bypass_incompatible_branch Bypass the check on the source branch prefix
/bypass_jira_check Bypass the Jira issue check
/bypass_peer_approval Bypass the pull request peers' approval
/bypass_leader_approval Bypass the pull request leaders' approval
/approve Instruct Bert-E that the author has approved the pull request. ✍️
/create_pull_requests Allow the creation of integration pull requests.
/create_integration_branches Allow the creation of integration branches.
/no_octopus Prevent Wall-E from doing any octopus merge and use multiple consecutive merge instead
/unanimity Change review acceptance criteria from one reviewer at least to all reviewers
/wait Instruct Bert-E not to run until further notice.
Available commands
name description privileged
/help Print Bert-E's manual in the pull request.
/status Print Bert-E's current status in the pull request TBA
/clear Remove all comments from Bert-E from the history TBA
/retry Re-start a fresh build TBA
/build Re-start a fresh build TBA
/force_reset Delete integration branches & pull requests, and restart merge process from the beginning.
/reset Try to remove integration branches unless there are commits on them which do not appear on the source branch.

Status report is not available.

@bert-e
Copy link
Contributor

bert-e commented Sep 19, 2024

Request integration branches

Waiting for integration branch creation to be requested by the user.

To request integration branches, please comment on this pull request with the following command:

/create_integration_branches

Alternatively, the /approve and /create_pull_requests commands will automatically
create the integration branches.

This moves the logic out of the OplogPopulator file.

Issue: BB-602
- The strategy manages a pipeline that listens to all buckets.

Issue: BB-602
@williamlardier williamlardier force-pushed the improvement/BB-602 branch 3 times, most recently from 00d2c2c to b9e5be6 Compare October 18, 2024 07:12
- Each facroty manages a specific type of pipeline.
- We use the pipeline in the allocation strategy.
- The Connector now uses the factory from the allocation strategy
  to create the right pipeline.
- The ConnectorsManager now rely on the allocation strategy to
  decide if an old connector should be kept or not, based on the
  old connector config, and the current allocation strategy.

Issue: BB-602
- This ensures we never listen to a bucket twice
- Handling of "transitions", i.e., to ensure there will be no
  event missed or seen twice, is out of scope, and will be
  covered by a procedure for now.

Issue: BB-602
@williamlardier williamlardier marked this pull request as ready for review October 18, 2024 07:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants