diff --git a/README.md b/README.md index f0bc54d0..c93f897d 100644 --- a/README.md +++ b/README.md @@ -60,6 +60,8 @@ The new registry implementation provides the following benefits: - pluggable storage backend - webhook notifications +For information on upcoming functionality, please see [ROADMAP.md](ROADMAP.md). + Installation ------------ diff --git a/ROADMAP.md b/ROADMAP.md new file mode 100644 index 00000000..fddc71b3 --- /dev/null +++ b/ROADMAP.md @@ -0,0 +1,91 @@ +# Roadmap + +The Distribution Project consists of several components, some of which are still being defined. This document defines the high-level goals of the project, identifies the current components, and defines the release-relationship to the Docker Platform. + +* [Distribution Goals](#distribution-goals) +* [Distribution Components](#distribution-components) +* [Project Planning](#project-planning): release-relationship to the Docker Platform. + +## Distribution Goals + +- Replace the existing [docker registry](github.com/docker/docker-registry) + implementation as the primary implementation. +- Replace the existing push and pull code in the docker engine with the + distribution package. +- Define a strong data model for distributing docker images +- Provide a flexible distribution tool kit for use in the docker platform + +## Distribution Components + +Components of the Distribution Project are managed via github [milestones](https://github.com/docker/distribution/milestones). Upcoming +features and bugfixes for a component will be added to the relevant milestone. If a feature or +bugfix is not part of a milestone, it is currently unscheduled for +implementation. + +* [Registry](#registry) +* [Distribution Package](#distribution-package) + +*** + +### Registry + +Registry 2.0 is the first release of the next-generation registry. This is primarily +focused on implementing the [new registry +API](https://github.com/docker/distribution/blob/master/doc/spec/api.md), with +a focus on security and performance. + +#### Registry 2.0 + +Features: + +- Faster push and pull +- New, more efficient implementation +- Simplified deployment +- Full API specification for V2 protocol +- Pluggable storage system (s3, azure, filesystem and inmemory supported) +- Immutable manifest references ([#46](https://github.com/docker/distribution/issues/46)) +- Webhook notification system ([#42](https://github.com/docker/distribution/issues/42)) +- Native TLS Support ([#132](https://github.com/docker/distribution/pull/132)) +- Pluggable authentication system +- Health Checks ([#230](https://github.com/docker/distribution/pull/230)) + +#### Registry 2.1 + +Planned Features: + +> **NOTE:** This feature list is incomplete at this time. + +- Support for Manifest V2, Schema 2 and explicit tagging objects ([#62](https://github.com/docker/distribution/issues/62), [#173](https://github.com/docker/distribution/issues/173)) +- Mirroring ([#19](https://github.com/docker/distribution/issues/19)) +- Flexible client package based on distribution interfaces ([#193](https://github.com/docker/distribution/issues/193) + +#### Registry 2.2 + +TBD + +*** + +### Distribution Package + +At its core, the Distribution Project is a set of Go packages that make up +Distribution Components. At this time, most of these packages make up the +Registry implementation. + +The package itself is considered unstable. If you're using it, please take care to vendor the dependent version. + +For feature additions, please see the Registry section. In the future, we may break out a +separate Roadmap for distribution-specific features that apply to more than +just the registry. + +*** + +### Project Planning + +Distribution Components map to Docker Platform Releases via the use of labels. Project Pages are used to define the set of features that are included in each Docker Platform Release. + +| Platform Version | Label | Planning | +|-----------|------|-----| +| Docker 1.6 | [Docker/1.6](https://github.com/docker/distribution/labels/docker%2F1.6) | [Project Page](https://github.com/docker/distribution/wiki/docker-1.6-Project-Page) | +| Docker 1.7| [Docker/1.7](https://github.com/docker/distribution/labels/docker%2F1.7) | [Project Page](https://github.com/docker/distribution/wiki/docker-1.7-Project-Page) | +| Docker 1.8| [Docker/1.8](https://github.com/docker/distribution/labels/docker%2F1.8) | [Project Page](https://github.com/docker/distribution/wiki/docker-1.8-Project-Page) | + diff --git a/open-design/MANIFESTO.md b/open-design/MANIFESTO.md deleted file mode 100644 index f3cd03da..00000000 --- a/open-design/MANIFESTO.md +++ /dev/null @@ -1,20 +0,0 @@ -# The "Distribution" project - -## What is this - -This is a part of the Docker project, or "primitive" that handles the "distribution" of images. - -### Punchline - -Pack. Sign. Ship. Store. Deliver. Verify. - -### Technical scope - -Distribution has tight relations with: - - * libtrust, providing cryptographical primitives to handle image signing and verification - * image format, as transferred over the wire - * docker-registry, the server side component that allows storage and retrieval of packed images - * authentication and key management APIs, that are used to verify images and access storage services - * PKI infrastructure - * docker "pull/push client" code gluing all this together - network communication code, tarsum, etc diff --git a/open-design/ROADMAP.md b/open-design/ROADMAP.md deleted file mode 100644 index 54e244ad..00000000 --- a/open-design/ROADMAP.md +++ /dev/null @@ -1,41 +0,0 @@ -# Roadmap - -## 11/24/2014: alpha - -Design and code: - -- implements a basic configuration loading mechanism: https://github.com/docker/docker-registry/issues/646 -- storage API is frozen, implemented and used: https://github.com/docker/docker-registry/issues/616 -- REST API defined and partly implemented: https://github.com/docker/docker-registry/issues/634 -- basic logging: https://github.com/docker/docker-registry/issues/635 -- auth design is frozen: https://github.com/docker/docker-registry/issues/623 - -Environment: - -- some good practice are in place and documented: https://github.com/docker/docker-registry/issues/657 - -## 12/22/2014: beta - -Design and code: - -- feature freeze -- mirroring defined: https://github.com/docker/docker-registry/issues/658 -- extension model defined: https://github.com/docker/docker-registry/issues/613 - -Environment: - -- doc-driven approach: https://github.com/docker/docker-registry/issues/627 - -## 01/12/2015: RC - -Design and code: - -- third party drivers and extensions -- basic search extension -- third-party layers garbage collection scripts -- healthcheck endpoints: https://github.com/docker/docker-registry/issues/656 -- bugnsnag/new-relic support: https://github.com/docker/docker-registry/issues/680 - -Environment: - -- exhaustive test-cases diff --git a/open-design/specs/TEMPLATE.md b/open-design/specs/TEMPLATE.md deleted file mode 100644 index a87ea61e..00000000 --- a/open-design/specs/TEMPLATE.md +++ /dev/null @@ -1,52 +0,0 @@ -# DEP #X: Awesome proposal - -## Scope - -This is related to "Foo" (eg: authentication/storage/extension/...). - -## Abstract - -This proposal suggests to add support for "bar". - -## User stories - -"I'm a Hub user, and 'bar' allows me to do baz1" - -"I'm a FOSS user running my private registry and 'bar' allows me to do baz2" - -"I'm a company running the registry and 'bar' allows me to do baz3" - -## Technology pre-requisites - -'bar' can be implemented using: - - * foobar approach - * barfoo concurrent approach - -## Dependencies - -Project depends on baz to be completed (eg: docker engine support, or another registry proposal). - -## Technical proposal - -We are going to do foofoo alongside with some chunks of barbaz. - -## Roadmap - - * YYYY-MM-DD: proposal submitted - * YYYY-MM-DD: proposal reviewed and updated - * YYYY-MM-DD: implementation started (WIP PR) - * YYYY-MM-DD: implementation complete ready for thorough review - * YYYY-MM-DD: final PR version - * YYYY-MM-DD: implementation merged - -## Editors - -Editors: - - * my Company, or maybe just me - -Implementors: - - * me and my buddies - * another team working on a different approach \ No newline at end of file