## Overview This epic covers the implementation of the Docker virtual registry feature in GitLab, building on our successful package virtual registry implementations. The Docker virtual registry will leverage our existing virtual registry architecture to provide a complete solution with multiple upstream sources, UI management, and cache clearing capabilities. ## Goals - Beta implementation of a Docker virtual registry with feature parity to our existing virtual registries - Provide comprehensive UI and API interfaces for creating, configuring, and managing Docker virtual registries - Support for multiple upstream sources with registry-specific authentication - Ensure seamless image resolution and proxying from multiple upstream sources - Validate performance and reliability with real-world usage patterns ## Scope ### In Scope - Create a Docker virtual registry with multiple upstream sources - Configure and manage shareable upstream configurations - - List and search virtual registries - Deleting a virtual registry - Image resolution and proxying from configured upstreams - Cache clearing capabilities - Comprehensive error handling and logging - Performance monitoring and optimization - Support for registries with long-lived token authentication (Docker Hub, Harbor, Quay) ### Out of Scope - Support for cloud provider registries requiring IAM authentication (ECR, Google Artifact Registry, Azure Container Registry) - planned for future iterations - Publishing to virtual registries (planned for post-beta) - Advanced caching policies beyond those already implemented for other registry types - UI for management of virtual registries ## User Stories 1. As a DevOps engineer, I want to create a Docker virtual registry via UI and API so that I can start aggregating container images from multiple upstream sources. 2. As a platform engineer, I want to configure multiple upstream sources for my virtual registry so that I can specify the order and priority of image resolution. 3. As a project maintainer, I want to share upstream configurations across multiple registries so that I can ensure consistency and reduce configuration overhead. 4. As a system administrator, I want to clear the cache for specific images or entire registries so that I can ensure my teams have access to the latest versions. 5. As a developer, I want to resolve and download Docker images through the virtual registry so that I can use it as a single source for my container dependencies. 6. As an administrator, I want to monitor the performance and usage of my Docker virtual registries so that I can optimize them for my organization's needs. ## Acceptance Criteria - UI and API interfaces are fully implemented and functional - Virtual registries correctly proxy images from multiple configured upstreams - Shareable upstream configurations work correctly across registries - Cache clearing functions operate as expected - Error scenarios are properly handled and logged - Documentation clearly explains all features and configuration options - Performance meets established benchmarks for high-volume container image usage - Test coverage meets GitLab standards ## Metrics for Success - Successful creation and configuration of registries via UI and API - Correct image resolution and download through virtual registries - Response times within acceptable thresholds under load - Error rates below defined thresholds - Cache hit ratios meeting or exceeding targets - Positive feedback from beta customers regarding usability and reliability ## Adoption Tracking and Analytics - Implement instrumentation to track the adoption and usage of virtual registries, including: * Total number of groups with the feature enabled * Number of images pulled from virtual registries * Cache hit ratio * UI usage data (e.g., number of virtual registries per group, number of upstream sources per virtual registry) ## Beta Customer Engagement Plan - **Recruitment**: Target 5-10 key customers with significant container usage for beta participation - **Onboarding**: Provide detailed documentation and dedicated support for initial setup - **Feedback Collection**: * Bi-weekly check-ins with beta participants * Structured feedback form for feature usability and performance * Bug reporting channel for immediate technical issues - **Success Tracking**: * Monitor usage metrics across beta participants * Track image resolution success rates and performance * Document customer use cases for future marketing materials - **Graduation Criteria**: * Zero P1 bugs reported for two consecutive weeks * Performance metrics meeting or exceeding targets * 80%+ of beta participants actively using the feature <!--triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION--> > [!important] > > This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc. <!--triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION-->