Group Level Wiki: BE Support Geo replication
In groupknowledge we've started to work on group wikis for 12.9 (&240 (closed)). There's no timeline on the release yet, but we'll keep it behind a feature flag until it's ready and currently expect that to take a few months.
I saw #121589 (closed), so I wanted to raise a similar issue for group wikis to discuss any potential challenges with Geo support.
So far we know:
- Each group can have one wiki repository.
- We haven't settled on a path format yet, @brodock suggested going with
@groups/#{hashed_path}/#{hashed_id}.wiki.gitat #196053 (comment 294529826).
- We haven't settled on a path format yet, @brodock suggested going with
- This is the first repository type on groups.
- Other types that we might add in the future are design management repos.
Activity columns for Geo
For project wikis, we're updating the projects.last_repository_updated_at column both synchronously for changes made through GitLab itself (via web UI or API), as well as a second time asynchronously for all changes made to the wiki repository (via the post-receive hook). This column indicates to Geo that the repository needs to be replicated, though we're also throttling updates to this column in certain cases.
For group wikis we need to check if we need a similar signaling mechanism for Geo, and we could also consider removing the first synchronous update because we're already doing it in the asynchronous call.
See discussions at !37439 (diffs, comment 405488754) and !37439 (diffs, comment 406180066).