Skip to content

WIP: POC: Self-service Geo

Michael Kozono requested to merge mk/poc-self-service-geo into master

What does this MR do?

This is a POC, still quite incomplete especially in tests.

Imagining the world post Self Service Geo Epic:

From the perspective of a non-Geo developer

Let's say you recently introduced class SnippetRepository < ::Repository, and you want to add Geo support.

  1. First, you read a developer doc to get an idea of how it works and where to start.
  2. You run a generator to create the registry model and table.
  3. You add shared_examples for a feature spec and for your model.
  4. You include the Replicable::Model and Replicable::Strategies::Repository::Model concerns.
  5. You start to fix your model spec and the new registry spec by filling in the required let variables and test methods.
  6. You implement the NotImplementedError methods.
  7. Keep fixing unit tests.
  8. Finally you start running the feature specs and fix anything until it passes. I.e. you call event emitters in the right places.

What did I do in this POC?

I tried to take over replication of Design repositories. Since it is already feature flagged, there is a chance we could actually merge a big change here (correct me if we shouldn't.)

I tried to treat Repository as the owner of its data, so we could switch Project and Wiki over to this after it's complete (including verification) and proven. Our repository replication strategy shouldn't directly reference design.

I even tried to reference project less, e.g. if we want to later have Git repositories uncoupled from Project, but in truth that would be a very hard task. This is made more difficult by the fact that Repository isn't represented directly in the database. I wouldn't be against undoing some of these hoops I jumped through.

In general, the Geo::DesignRegistry knows everything specific to syncing a Design repository, or it knows who to call. So instead of writing conditionals by repo type, ask the Registry.

Geo::ReplicableEvent is the new Single Queue @toon described.

Events are generated from the owner of the data, Repository. Call replicable_update on it when needed.

ReplicableRepositorySyncWorker and ReplicableRepositorySyncService, as part of the Repository Strategy, are intended to be able to support project and wiki as well. Again, specifics are asked of the Registry.

Screenshots

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • Label as security and @ mention @gitlab-com/gl-security/appsec
  • The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • Security reports checked/validated by a reviewer from the AppSec team
Edited by Michael Kozono

Merge request reports