Discussion: Consider Dropping Support for Less-Used Storage Drivers
Context
Storage Drivers allow the registry to work with various object storage platforms. While each driver's code is relatively self-contained, the maintenance burden of these drivers is relatively large:
- each driver implementation is unique
- most require importing large, complex libraries with many dependencies
- making changes to a driver requires a fairly high level of domain expertise with the storage backend enabled by that driver
- each developer needs access to each backend, most of which are not free
- changes to the storage driver interface need to be validated against all implementation to ensure they are feasible
- storage drivers are an essential component of many important registry operations, and implementation errors can bubble up and effect large portions of the code
Problem
Asking self-managed users, even a small number, to move away from storage backends is not something we should consider lightly. This is a large, disruptive operation, and the users that need to migrate do not gain immediate benefit for having done so.
Looking at object storage options for the GitLab application itself, it appears we could only potentially remove support for OSS and the native Swift driver and still be aligned with the broader product offering. Despite this, removing or deprecating these two drivers does cuts down on enough maintenance burden to strongly consider.
Solution
Technically, this is a relatively straightforward deprecate/remove scenario. Drivers and their tests are relatively self-contained, so the difficulty here is mostly from a product perspective — ensuring these removals do not affect too many users and that we provide enough time for any users to migrate away from their current storage setups.
Impact
Reduces maintenance and support burden.