Implement Dynamic Media Types with SMALLINT
Context
When we first introduced the new architecture with a metadata database, we decided to keep a list of allowed media types and deny pushes for any outside that list.
We did so mainly for safety/integrity reasons as we were about to start the GitLab.com upgrade/migration (&5523 (closed)). As part of that, we wanted to know what kind of images we were porting from the old to the new registry and validate any unknown ones, ensuring they were fully compatible with the new registry schema and data integrity would be preserved.
Proposal
Now that the migration is over and we have a stable system, we can relax this validation and accept new media types as they appear. To do so we must adapt the existing solution to add new media types in the media_types
table whenever necessary.
For observability reasons, we must emit a unique log entry to let us know that a new media type has been added. This will contribute to awareness (knowing new tools in the containers ecosystem as they pop up).
This iteration will use the original SMALLINT media type IDs and be behind a feature flag. We can't roll this out to GitLab.com until work on is complete.
Implementation Plan
-
Create A Feature Flag for Dynamic Media Types -
Refactor mapMediaType
into media type store method -
Add a constraint to prevent empty string inserts on mt table -
Add a function to the media type store to Find or Create Media types -
Enable dynamic feature flags for API operations -
Update Media Types Support Documentation -
Import with dynamic media types by default