-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
feat(backup): Enable export over RPC #57740
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
Conversation
This finishes out the work started in #57740 and enables imports over RPC as well. Like that PR, imports are already done on a sequential, per model basis, so this change just consists of moving every such call across an RPC boundary. Closes getsentry/team-ospo#196
30e058c to
abf878c
Compare
0ef3704 to
f87f84f
Compare
This finishes out the work started in #57740 and enables imports over RPC as well. Like that PR, imports are already done on a sequential, per model basis, so this change just consists of moving every such call across an RPC boundary. Closes getsentry/team-ospo#196
abf878c to
e0c8734
Compare
f87f84f to
c587ad3
Compare
ce029d5 to
00aa0dc
Compare
c587ad3 to
e362bd8
Compare
5833527 to
f91f271
Compare
e362bd8 to
2b66385
Compare
f91f271 to
9e83388
Compare
2b66385 to
5516fd8
Compare
Codecov Report
@@ Coverage Diff @@
## master #57740 +/- ##
==========================================
+ Coverage 79.02% 79.03% +0.01%
==========================================
Files 5130 5134 +4
Lines 223033 223269 +236
Branches 37566 37599 +33
==========================================
+ Hits 176255 176466 +211
- Misses 41140 41166 +26
+ Partials 5638 5637 -1
|
5516fd8 to
1bf2a99
Compare
1bf2a99 to
ffc3ec2
Compare
ffc3ec2 to
b3e662f
Compare
b3e662f to
2066756
Compare
2066756 to
3c9bc6c
Compare
3c9bc6c to
ae98c03
Compare
Exports are already done on a sequential, per-model basis, going in reverse dependency order. This change modifies that scheme to work across an RPC boundary: code running on REGION instances (the only kind of instance that may perform import/export operations) requests the exports using either the local implementation (if the model is REGION as well), or by sending an RPC call to the same method on the remote CONTROL silo instance. Code executed in MONOLITH mode (aka, self-hosted and single tenant instances) does all exporting locally. The new `import_export_service` is thus a bit different from some of the others in `hybrid_cloud`. Whereas existing services like `Access` provide a means to get the same information using different logic depending on which Silo they are located in (ex: using `Organization` or `OrganizationMapping` as the source of truth), this service executes identical logic in all silo kinds, and requires users to pick the implementation themselves. That is, users must examine the model they are about to request be exported, and make their own decision as to which implementation, remote or local, to use. This is a bit unergonomic compared to other `hybrid_cloud` services, but it is only used by one rather unique endpoint (the import/export functions) for a very specific purpose, making this API a bit easier to swallow. Issue: getsentry/team-ospo#196
ae98c03 to
2ffec79
Compare
This finishes out the work started in #57740 and enables imports over RPC as well. Like that PR, imports are already done on a sequential, per model basis, so this change just consists of moving every such call across an RPC boundary. Closes getsentry/team-ospo#185 Closes getsentry/team-ospo#196
hubertdeng123
left a comment
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.
did a tentative scan and looks fine to me, but I'm lacking context. +1 to unblock
This finishes out the work started in #57740 and enables imports over RPC as well. Like that PR, imports are already done on a sequential, per model basis, so this change just consists of moving every such call across an RPC boundary. Closes getsentry/team-ospo#185 Closes getsentry/team-ospo#196
This finishes out the work started in #57740 and enables imports over RPC as well. Like that PR, imports are already done on a sequential, per model basis, so this change just consists of moving every such call across an RPC boundary. Closes getsentry/team-ospo#185 Closes getsentry/team-ospo#196
feat(backup): Enable imports over RPC This finishes out the work started in #57740 and enables imports over RPC as well. Like that PR, imports are already done on a sequential, per model basis, so this change just consists of moving every such call across an RPC boundary. Closes getsentry/team-ospo#185 Closes getsentry/team-ospo#196 Closes getsentry/team-ospo#202
This finishes out the work started in #57740 and enables imports over RPC as well. Like that PR, imports are already done on a sequential, per model basis, so this change just consists of moving every such call across an RPC boundary. This is a second attempt at landing this PR, with fewer tests tested in both modes.
This finishes out the work started in #57740 and enables imports over RPC as well. Like that PR, imports are already done on a sequential, per model basis, so this change just consists of moving every such call across an RPC boundary. This is a second attempt at landing this PR, with fewer tests tested in both modes.
Exports are already done on a sequential, per-model basis, going in reverse dependency order. This change modifies that scheme to work across an RPC boundary: code running on REGION instances (the only kind of instance that may perform import/export operations) requests the exports using either the local implementation (if the model is REGION as well), or by sending an RPC call to the same method on the remote CONTROL silo instance. Code executed in MONOLITH mode (aka, self-hosted and single tenant instances) does all exporting locally.
The new
import_export_serviceis thus a bit different from some of the others inhybrid_cloud. Whereas existing services likeAccessprovide a means to get the same information using different logic depending on which Silo they are located in (ex: usingOrganizationorOrganizationMappingas the source of truth), this service executes identical logic in all silo kinds, and requires users to pick the implementation themselves. That is, users must examine the model they are about to request be exported, and make their own decision as to which implementation, remote or local, to use. This is a bit unergonomic compared to otherhybrid_cloudservices, but it is only used by one rather unique endpoint (the import/export functions) for a very specific purpose, making this API a bit easier to swallow.Issue: getsentry/team-ospo#196