Let's define the approach by which users will configure the next-gen registry:

First, some use cases:

1. I want to run a simple registry in container form with a default storage driver (local filesystem or S3) and want to provide the relevant parameters.
2. I want to configure a persistent registry with many fine-tuned parameters.
3. I want to manage multiple registries and manage my configurations in one place.

Current solutions:

1. Parameters can be provided via environment variables at runtime. Example shown below:

   docker run \
            -e SETTINGS_FLAVOR=s3 \
            -e AWS_BUCKET=mybucket \
            -e STORAGE_PATH=/registry \
            -e AWS_KEY=myawskey \
            -e AWS_SECRET=myawssecret \
            -e SEARCH_BACKEND=sqlalchemy \
            -p 5000:5000 \
           registry
   

2. Edit the config.yml and provide it to the container with a shared volume

3. Same as 2, but with an NFS volume or a synchronized directory(?)

Proposed solutions:

1. Keep the same behavior with environment variables. We may want to do a better job namespacing configuration variables for storage drivers though. For instance, the s3 driver, we provide AWS_BUCKET and AWS_KEY, but perhaps these should be S3_BUCKET and S3_AWS_KEY or S3_KEY.
2. We should probably still use a YAML configuration file, although we should be more conscious of versioning, as to avoid requiring a rewrite of configuration files on each version change. The registry could continue to use old configuration file versions up to a point, as long as we're explicit in specifying the configuration version.
3. Allow the registry to use a URL to point at a YAML configuration, as hosted on a web server somewhere. This allows us to update the configuration in one place and have the changes propagate to all registries using this configuration endpoint (great for mirroring setups).