Skip to content

objectpool: Switch to use OptimizeRepository for pool repos

Patrick Steinhardt requested to merge pks-object-pools-optimize-repository into master

The equivalent to a housekeeping job for object pools is our FetchIntoObjectPool RPC: it fetches all changes from the primary pool member and then optimizes the repository. Its implementation is separate from housekeeping.OptimizeRepository() though which creates a world where we have two parallel implementations of repository housekeeping, which goes against our principle of a single source of truth.

More importantly though pool repositories may not only be optimized via FetchIntoObjectPool, but also via our nightly repository housekeeping job. So we already use both implementations to pack a repository. And sure enough, they had some subtle differences already like delta islands not being the same. Furthermore, OptimizeRepository is doing some things like keeping commit-graphs up to date that FetchIntoObjectPool doesn't.

Unify the infrastructure so that we only have a one maintenance strategy to worry about: OptimizeRepository. This has multiple benefits:

- We avoid any future divergence in behaviour.

- We have less code to worry about.

- Nightly maintenance and on-demand maintenance use the same code
  paths.

- Commit-graphs are kept up to date again, which is something that
  has been broken in object pools for quite a while.

- We avoid doing needless work when there is not much to be done
  thanks to the heuristisc of OptimizeRepository.

- We avoid running repository maintenance concurrently on the same
  pool repository given that OptimizeRepository exits early when it
  sees a concurrent call to the same repository.

The new strategy is guarded by a feature flag for the time being.

Fixes #4338 (closed).

Part of #2359 (closed).

Merge request reports