[registry-operator]: scope of MVP

[malgorzatadutka]

Context and Problem Statement

Minimum Viable Product (MVP) refers to the initial version of a product that includes only the essential features needed to meet the needs of early adopters and gather feedback for future development.

MVP should be defined at the beginning of our project. If it comes to the storage implementation we can consider splitting work into main features:

• filesystem
• azure
• gcs
• s3

Moreover the Registry configuration file contains many parameters connected with logging, hooks, authorization, http server configuration. Please see: https://distribution.github.io/distribution/about/configuration/

Considered Options

The MVP can contain the two protocols:

• filesystem - using CSI support
• s3 (fields: accesskey, secretkey, region, regionendpoint, bucket) - using COSI support

It can implement configuring other fields such as:

• storage.inmemory - uses inmemory storage driver for tests purposes
• storage.delete - enables the deletion of image blobs and manifests by digest
• storage.maintanance - enables maintanance functions like uploadpurging and readonly.
• auth.token - configures authentication provider

Please remember that a well-defined scope enhances the efficiency of MVP development and the overall success of the product.

[shanduur]

What about providing only plain minimum for v0.1.1, e.g. deploying deployment with one replica of registry with only default configuration (this means mounting no config) and creating a simple service?

flowchart TD
    A["registry-operator.dev/v1alpha1\nRegistry (1)"] --> B["apps/v1\nDeployment (2)"]
    A --> C["v1\nService (3)"]

1. Registry:

   apiVersion: registry-operator.dev/v1alpha1
   kind: Registry
   metadata:
   name: simplest
   namespace: foo
   spec: {}

2. Deployment:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
   name: simplest
   spec:
   replicas: 1
   selector:
     matchLabels:
       app: registry
   template:
     metadata:
       labels:
         app: registry
     spec:
       containers:
       - name: registry
         image: 'docker.io/library/registry:2.8.3'
         ports:
         - containerPort: 5000

3. Service:

   apiVersion: v1
   kind: Service
   metadata:
   name: simplest
   spec:
   selector:
     app: simplest-registry
   ports:
   - port: 5000
     targetPort: 5000

[malgorzatadutka]

Well, it is the simplest possible solution. In this case we don't need to communicate with CSI/COSI CRs, but on the other hand we won't test any specific scenarios connected with communication with driver's resources. I understand that the MVP will be fulfilled, because the Registry will be successfully configured, but we won't develop Registry CRD.

The plan: 1) 0.1.0 - configuring Registry with default configuration 2) 0.2.0 - configuring with s3 3) 0.3.0 - configuring with filesystem ...

@purpleturtll @shanduur @majabojarska @niesmaczne I'm working on the architectural draft here: https://github.com/registry-operator/adr/wiki

[shanduur]

LGTM. As a result of this ADR, could you please create a Roadmap (either as an issue or a ROADMAP.md file in registry-operator/registry-operator) and create milestones for v0.1.0 and v0.2.0?