You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
0 commit comments