You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<
8000
script type="application/json" data-target="react-app.embeddedData">{"payload":{"allShortcutsEnabled":false,"fileTree":{"":{"items":[{"name":"cmd","path":"cmd","contentType":"directory"},{"name":"configuration","path":"configuration","contentType":"directory"},{"name":"context","path":"context","contentType":"directory"},{"name":"contrib","path":"contrib","contentType":"directory"},{"name":"digestset","path":"digestset","contentType":"directory"},{"name":"docs","path":"docs","contentType":"directory"},{"name":"health","path":"health","contentType":"directory"},{"name":"manifest","path":"manifest","contentType":"directory"},{"name":"metrics","path":"metrics","contentType":"directory"},{"name":"notifications","path":"notifications","contentType":"directory"},{"name":"project","path":"project","contentType":"directory"},{"name":"reference","path":"reference","contentType":"directory"},{"name":"registry","path":"registry","contentType":"directory"},{"name":"releases","path":"releases","contentType":"directory"},{"name":"script","path":"script","contentType":"directory"},{"name":"testutil","path":"testutil","contentType":"directory"},{"name":"uuid","path":"uuid","contentType":"directory"},{"name":"vendor","path":"vendor","contentType":"directory"},{"name":"version","path":"version","contentType":"directory"},{"name":".gitignore","path":".gitignore","contentType":"file"},{"name":".gometalinter.json","path":".gometalinter.json","contentType":"file"},{"name":".mailmap","path":".mailmap","contentType":"file"},{"name":".travis.yml","path":".travis.yml","contentType":"file"},{"name":"BUILDING.md","path":"BUILDING.md","contentType":"file"},{"name":"CONTRIBUTING.md","path":"CONTRIBUTING.md","contentType":"file"},{"name":"Dockerfile","path":"Dockerfile","contentType":"file"},{"name":"LICENSE","path":"LICENSE","contentType":"file"},{"name":"MAINTAINERS","path":"MAINTAINERS","contentType":"file"},{"name":"Makefile","path":"Makefile","contentType":"file"},{"name":"README.md","path":"README.md","contentType":"file"},{"name":"ROADMAP.md","path":"ROADMAP.md","contentType":"file"},{"name":"blobs.go","path":"blobs.go","contentType":"file"},{"name":"doc.go","path":"doc.go","contentType":"file"},{"name":"errors.go","path":"errors.go","contentType":"file"},{"name":"manifests.go","path":"manifests.go","contentType":"file"},{"name":"registry.go","path":"registry.go","contentType":"file"},{"name":"tags.go","path":"tags.go","contentType":"file"},{"name":"vendor.conf","path":"vendor.conf","contentType":"file"}],"totalCount":38}},"fileTreeProcessingTime":7.73738,"foldersToFetch":[],"incompleteFileTree":false,"repo":{"id":156820676,"defaultBranch":"master","name":"distribution","ownerLogin":"jimmyyan","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2018-11-09T06:36:24.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/4156489?v=4","public":true,"private":false,"isOrgOwned":false},"codeLineWrapEnabled":false,"symbolsExpanded":false,"treeExpanded":true,"refInfo":{"name":"master","listCacheKey":"v0:1617051351.0128598","canEdit":false,"refType":"branch","currentOid":"c04a3d91fff3ac0c279d9107acf6b842c26e0153"},"path":"ROADMAP.md","currentUser":null,"blob":{"rawLines":null,"stylingDirectives":null,"colorizedLines":null,"csv":null,"csvError":null,"dependabotInfo":{"showConfigurationBanner":false,"configFilePath":null,"networkDependabotPath":"/jimmyyan/distribution/network/updates","dismissConfigurationNoticePath":"/settings/dismiss-notice/dependabot_configuration_notice","configurationNoticeDismissed":null},"displayName":"ROADMAP.md","displayUrl":"https://github.com/jimmyyan/distribution/blob/master/ROADMAP.md?raw=true","headerInfo":{"blobSize":"13.1 KB","deleteTooltip":"You must be signed in to make or propose changes","editTooltip":"You must be signed in to make or propose changes","ghDesktopPath":"https://desktop.github.com","isGitLfs":false,"onBranch":true,"shortPath":"701127a","siteNavLoginPath":"/login?return_to=https%3A%2F%2Fgithub.com%2Fjimmyyan%2Fdistribution%2Fblob%2Fmaster%2FROADMAP.md","isCSV":false,"isRichtext":true,"toc":[{"level":1,"text":"Roadmap","anchor":"roadmap","htmlText":"Roadmap"},{"level":2,"text":"Distribution Goals","anchor":"distribution-goals","htmlText":"Distribution Goals"},{"level":2,"text":"Distribution Components","anchor":"distribution-components","htmlText":"Distribution Components"},{"level":3,"text":"Registry","anchor":"registry","htmlText":"Registry"},{"level":4,"text":"Data Storage and Distribution First","anchor":"data-storage-and-distribution-first","htmlText":"Data Storage and Distribution First"},{"level":4,"text":"Content Addressability","anchor":"content-addressability","htmlText":"Content Addressability"},{"level":4,"text":"Content Agnostic","anchor":"content-agnostic","htmlText":"Content Agnostic"},{"level":4,"text":"Simplicity","anchor":"simplicity","htmlText":"Simplicity"},{"level":4,"text":"Extensibility","anchor":"extensibility","htmlText":"Extensibility"},{"level":4,"text":"Active Feature Discussions","anchor":"active-feature-discussions","htmlText":"Active Feature Discussions"},{"level":5,"text":"Proxying to other Registries","anchor":"proxying-to-other-registries","htmlText":"Proxying to other Registries"},{"level":5,"text":"Metadata storage","anchor":"metadata-storage","htmlText":"Metadata storage"},{"level":5,"text":"Peer to Peer transfer","anchor":"peer-to-peer-transfer","htmlText":"Peer to Peer transfer"},{"level":5,"text":"Indexing, Search and Discovery","anchor":"indexing-search-and-discovery","htmlText":"Indexing, Search and Discovery"},{"level":5,"text":"Deletes","anchor":"deletes","htmlText":"Deletes"},{"level":3,"text":"Distribution Package","anchor":"distribution-package","htmlText":"Distribution Package"},{"level":3,"text":"Project Planning","anchor":"project-planning","htmlText":"Project Planning"}],"lineInfo":{"truncatedLoc":"267","truncatedSloc":"204"},"mode":"file"},"image":false,"isCodeownersFile":null,"isPlain":false,"isValidLegacyIssueTemplate":false,"issueTemplate":null,"discussionTemplate":null,"language":"Markdown","languageID":222,"large":false,"planSupportInfo":{"repoIsFork":null,"repoOwnedByCurrentUser":null,"requestFullPath":"/jimmyyan/distribution/blob/master/ROADMAP.md","showFreeOrgGatedFeatureMessage":null,"showPlanSupportBanner":null,"upgradeDataAttributes":null,"upgradePath":null},"publishBannersInfo":{"dismissActionNoticePath":"/settings/dismiss-notice/publish_action_from_dockerfile","releasePath":"/jimmyyan/distribution/releases/new?marketplace=true","showPublishActionBanner":false},"rawBlobUrl":"https://github.com/jimmyyan/distribution/raw/refs/heads/master/ROADMAP.md","renderImageOrRaw":false,"richText":"\u003carticle class=\"markdown-body entry-content container-lg\" itemprop=\"text\"\u003e\u003cdiv class=\"markdown-heading\" dir=\"auto\"\u003e\u003ch1 tabindex=\"-1\" class=\"heading-element\" dir=\"auto\"\u003eRoadmap\u003c/h1\u003e\u003ca id=\"user-content-roadmap\" class=\"anchor\" aria-label=\"Permalink: Roadmap\" href=\"#roadmap\"\u003e\u003csvg class=\"octicon octicon-link\" viewBox=\"0 0 16 16\" version=\"1.1\" width=\"16\" height=\"16\" aria-hidden=\"true\"\u003e\u003cpath d=\"m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z\"\u003e\u003c/path\u003e\u003c/svg\u003e\u003c/a\u003e\u003c/div\u003e\n\u003cp dir=\"auto\"\u003eThe Distribution Project consists of several components, some of which are\nstill being defined. This document defines the high-level goals of the\nproject, identifies the current components, and defines the release-\nrelationship to the Docker Platform.\u003c/p\u003e\n\u003cul dir=\"auto\"\u003e\n\u003cli\u003e\u003ca href=\"#distribution-goals\"\u003eDistribution Goals\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#distribution-components\"\u003eDistribution Components\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#project-planning\"\u003eProject Planning\u003c/a\u003e: release-relationship to the Docker Platform.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp dir=\"auto\"\u003eThis road map is a living document, providing an overview of the goals and\nconsiderations made in respect of the future of the project.\u003c/p\u003e\n\u003cdiv class=\"markdown-heading\" dir=\"auto\"\u003e\u003ch2 tabindex=\"-1\" class=\"heading-element\" dir=\"auto\"\u003eDistribution Goals\u003c/h2\u003e\u003ca id=\"user-content-distribution-goals\" class=\"anchor\" aria-label=\"Permalink: Distribution Goals\" href=\"#distribution-goals\"\u003e\u003csvg class=\"octicon octicon-link\" viewBox=\"0 0 16 16\" version=\"1.1\" width=\"16\" height=\"16\" aria-hidden=\"true\"\u003e\u003cpath d=\"m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z\"\u003e\u003c/path\u003e\u003c/svg\u003e\u003c/a\u003e\u003c/div\u003e\n\u003cul dir=\"auto\"\u003e\n\u003cli\u003eReplace the existing \u003ca href=\"/jimmyyan/distribution/blob/master/github.com/docker/docker-registry\"\u003edocker registry\u003c/a\u003e\nimplementation as the primary implementation.\u003c/li\u003e\n\u003cli\u003eReplace the existing push and pull code in the docker engine with the\ndistribution package.\u003c/li\u003e\n\u003cli\u003eDefine a strong data model for distributing docker images\u003c/li\u003e\n\u003cli\u003eProvide a flexible distribution tool kit for use in the docker platform\u003c/li\u003e\n\u003cli\u003eUnlock new distribution models\u003c/li\u003e\n\u003c/ul\u003e\n\u003cdiv class=\"markdown-heading\" dir=\"auto\"\u003e\u003ch2 tabindex=\"-1\" class=\"heading-element\" dir=\"auto\"\u003eDistribution Components\u003c/h2\u003e\u003ca id=\"user-content-distribution-components\" class=\"anchor\" aria-label=\"Permalink: Distribution Components\" href=\"#distribution-components\"\u003e\u003csvg class=\"octicon octicon-link\" viewBox=\"0 0 16 16\" version=\"1.1\" width=\"16\" height=\"16\" aria-hidden=\"true\"\u003e\u003cpath d=\"m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z\"\u003e\u003c/path\u003e\u003c/svg\u003e\u003c/a\u003e\u003c/div\u003e\n\u003cp dir=\"auto\"\u003eComponents of the Distribution Project are managed via github \u003ca href=\"https://github.com/docker/distribution/milestones\"\u003emilestones\u003c/a\u003e. Upcoming\nfeatures and bugfixes for a component will be added to the relevant milestone. If a feature or\nbugfix is not part of a milestone, it is currently unscheduled for\nimplementation.\u003c/p\u003e\n\u003cul dir=\"auto\"\u003e\n\u003cli\u003e\u003ca href=\"#registry\"\u003eRegistry\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"#distribution-package\"\u003eDistribution Package\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003cdiv class=\"markdown-heading\" dir=\"auto\"\u003e\u003ch3 tabindex=\"-1\" class=\"heading-element\" dir=\"auto\"\u003eRegistry\u003c/h3\u003e\u003ca id=\"user-content-registry\" class=\"anchor\" aria-label=\"Permalink: Registry\" href=\"#registry\"\u003e\u003csvg class=\"octicon octicon-link\" viewBox=\"0 0 16 16\" version=\"1.1\" width=\"16\" height=\"16\" aria-hidden=\"true\"\u003e\u003cpath d=\"m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z\"\u003e\u003c/path\u003e\u003c/svg\u003e\u003c/a\u003e\u003c/div\u003e\n\u003cp dir=\"auto\"\u003eThe new Docker registry is the main portion of the distribution repository.\nRegistry 2.0 is the first release of the next-generation registry. This was\nprimarily focused on implementing the \u003ca href=\"https://github.com/docker/distribution/blob/master/docs/spec/api.md\"\u003enew registry\nAPI\u003c/a\u003e,\nwith a focus on security and performance.\u003c/p\u003e\n\u003cp dir=\"auto\"\u003eFollowing from the Distribution project goals above, we have a set of goals\nfor registry v2 that we would like to follow in the design. New features\nshould be compared against these goals.\u003c/p\u003e\n\u003cdiv class=\"markdown-heading\" dir=\"auto\"\u003e\u003ch4 tabindex=\"-1\" class=\"heading-element\" dir=\"auto\"\u003eData Storage and Distribution First\u003c/h4\u003e\u003ca id=\"user-content-data-storage-and-distribution-first\" class=\"anchor\" aria-label=\"Permalink: Data Storage and Distribution First\" href=\"#data-storage-and-distribution-first\"\u003e\u003csvg class=\"octicon octicon-link\" viewBox=\"0 0 16 16\" version=\"1.1\" width=\"16\" height=\"16\" aria-hidden=\"true\"\u003e\u003cpath d=\"m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z\"\u003e\u003c/path\u003e\u003c/svg\u003e\u003c/a\u003e\u003c/div\u003e\n\u003cp dir=\"auto\"\u003eThe registry's first goal is to provide a reliable, consistent storage\nlocation for Docker images. The registry should only provide the minimal\namount of indexing required to fetch image data and no more.\u003c/p\u003e\n\u003cp dir=\"auto\"\u003eThis means we should be selective in new features and API additions, including\nthose that may require expensive, ever growing indexes. Requests should be\nservable in \"constant time\".\u003c/p\u003e\n\u003cdiv class=\"markdown-heading\" dir=\"auto\"\u003e\u003ch4 tabindex=\"-1\" class=\"heading-element\" dir=\"auto\"\u003eContent Addressability\u003c/h4\u003e\u003ca id=\"user-content-content-addressability\" class=\"anchor\" aria-label=\"Permalink: Content Addressability\" href=\"#content-addressability\"\u003e\u003csvg class=\"octicon octicon-link\" viewBox=\"0 0 16 16\" version=\"1.1\" width=\"16\" height=\"16\" aria-hidden=\"true\"\u003e\u003cpath d=\"m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z\"\u003e\u003c/path\u003e\u003c/svg\u003e\u003c/a\u003e\u003c/div\u003e\n\u003cp dir=\"auto\"\u003eAll data objects used in the registry API should be content addressable.\nContent identifiers should be secure and verifiable. This provides a secure,\nreliable base from which to build more advanced content distribution systems.\u003c/p\u003e\n\u003cdiv class=\"markdown-heading\" dir=\"auto\"\u003e\u003ch4 tabindex=\"-1\" class=\"heading-element\" dir=\"auto\"\u003eContent Agnostic\u003c/h4\u003e\u003ca id=\"user-content-content-agnostic\" class=\"anchor\" aria-label=\"Permalink: Content Agnostic\" href=\"#content-agnostic\"\u003e\u003csvg class=\"octicon octicon-link\" viewBox=\"0 0 16 16\" version=\"1.1\" width=\"16\" height=\"16\" aria-hidden=\"true\"\u003e\u003cpath d=\"m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z\"\u003e\u003c/path\u003e\u003c/svg\u003e\u003c/a\u003e\u003c/div\u003e\n\u003cp dir=\"auto\"\u003eIn the past, changes to the image format would require large changes in Docker\nand the Registry. By decoupling the distribution and image format, we can\nallow the formats to progress without having to coordinate between the two.\nThis means that we should be focused on decoupling Docker from the registry\njust as much as decoupling the registry from Docker. Such an approach will\nallow us to unlock new distribution models that haven't been possible before.\u003c/p\u003e\n\u003cp dir=\"auto\"\u003eWe can take this further by saying that the new registry should be content\nagnostic. The registry provides a model of names, tags, manifests and content\naddresses and that model can be used to work with content.\u003c/p\u003e\n\u003cdiv class=\"markdown-heading\" dir=\"auto\"\u003e\u003ch4 tabindex=\"-1\" class=\"heading-element\" dir=\"auto\"\u003eSimplicity\u003c/h4\u003e\u003ca id=\"user-content-simplicity\" class=\"anchor\" aria-label=\"Permalink: Simplicity\" href=\"#simplicity\"\u003e\u003csvg class=\"octicon octicon-link\" viewBox=\"0 0 16 16\" version=\"1.1\" width=\"16\" height=\"16\" aria-hidden=\"true\"\u003e\u003cpath d=\"m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z\"\u003e\u003c/path\u003e\u003c/svg\u003e\u003c/a\u003e\u003c/div\u003e\n\u003cp dir=\"auto\"\u003eThe new registry should be closer to a microservice component than its\npredecessor. This means it should have a narrower API and a low number of\nservice dependencies. It should be easy to deploy.\u003c/p\u003e\n\u003cp dir=\"auto\"\u003eThis means that other solutions should be explored before changing the API or\nadding extra dependencies. If functionality is required, can it be added as an\nextension or companion service.\u003c/p\u003e\n\u003cdiv class=\"markdown-heading\" dir=\"auto\"\u003e\u003ch4 tabindex=\"-1\" class=\"heading-element\" dir=\"auto\"\u003eExtensibility\u003c/h4\u003e\u003ca id=\"user-content-extensibility\" class=\"anchor\" aria-label=\"Permalink: Extensibility\" href=\"#extensibility\"\u003e\u003csvg class=\"octicon octicon-link\" viewBox=\"0 0 16 16\" version=\"1.1\" width=\"16\" height=\"16\" aria-hidden=\"true\"\u003e\u003cpath d=\"m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z\"\u003e\u003c/path\u003e\u003c/svg\u003e\u003c/a\u003e\u003c/div\u003e\n\u003cp dir=\"auto\"\u003eThe registry should provide extension points to add functionality. By keeping\nthe scope narrow, but providing the ability to add functionality.\u003c/p\u003e\n\u003cp dir=\"auto\"\u003eFeatures like search, indexing, synchronization and registry explorers fall\ninto this category. No such feature should be added unless we've found it\nimpossible to do through an extension.\u003c/p\u003e\n\u003cdiv class=\"markdown-heading\" dir=\"auto\"\u003e\u003ch4 tabindex=\"-1\" class=\"heading-element\" dir=\"auto\"\u003eActive Feature Discussions\u003c/h4\u003e\u003ca id=\"user-content-active-feature-discussions\" class=\"anchor\" aria-label=\"Permalink: Active Feature Discussions\" href=\"#active-feature-discussions\"\u003e\u003csvg class=\"octicon octicon-link\" viewBox=\"0 0 16 16\" version=\"1.1\" width=\"16\" height=\"16\" aria-hidden=\"true\"\u003e\u003cpath d=\"m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z\"\u003e\u003c/path\u003e\u003c/svg\u003e\u003c/a\u003e\u003c/div\u003e\n\u003cp dir=\"auto\"\u003eThe following are feature discussions that are currently active.\u003c/p\u003e\n\u003cp dir=\"auto\"\u003eIf you don't see your favorite, unimplemented feature, feel free to contact us\nvia IRC or the mailing list and we can talk about adding it. The goal here is\nto make sure that new features go through a rigid design process before\nlanding in the registry.\u003c/p\u003e\n\u003cdiv class=\"markdown-heading\" dir=\"auto\"\u003e\u003ch5 tabindex=\"-1\" class=\"heading-element\" dir=\"auto\"\u003eProxying to other Registries\u003c/h5\u003e\u003ca id=\"user-content-proxying-to-other-registries\" class=\"anchor\" aria-label=\"Permalink: Proxying to other Registries\" href=\"#proxying-to-other-registries\"\u003e\u003csvg class=\"octicon octicon-link\" viewBox=\"0 0 16 16\" version=\"1.1\" width=\"16\" height=\"16\" aria-hidden=\"true\"\u003e\u003cpath d=\"m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z\"\u003e\u003c/path\u003e\u003c/svg\u003e\u003c/a\u003e\u003c/div\u003e\n\u003cp dir=\"auto\"\u003eA \u003cem\u003epull-through caching\u003c/em\u003e mode exists for the registry, but is restricted from\nwithin the docker client to only mirror the official Docker Hub. This functionality\ncan be expanded when image provenance has been specified and implemented in the\ndistribution project.\u003c/p\u003e\n\u003cdiv class=\"markdown-heading\" dir=\"auto\"\u003e\u003ch5 tabindex=\"-1\" class=\"heading-element\" dir=\"auto\"\u003eMetadata storage\u003c/h5\u003e\u003ca id=\"user-content-metadata-storage\" class=\"anchor\" aria-label=\"Permalink: Metadata storage\" href=\"#metadata-storage\"\u003e\u003csvg class=\"octicon octicon-link\" viewBox=\"0 0 16 16\" version=\"1.1\" width=\"16\" height=\"16\" aria-hidden=\"true\"\u003e\u003cpath d=\"m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z\"\u003e\u003c/path\u003e\u003c/svg\u003e\u003c/a\u003e\u003c/div\u003e\n\u003cp dir=\"auto\"\u003eMetadata for the registry is currently stored with the manifest and layer data on\nthe storage backend. While this is a big win for simplicity and reliably maintaining\nstate, it comes with the cost of consistency and high latency. The mutable registry\nmetadata operations should be abstracted behind an API which will allow ACID compliant\nstorage systems to handle metadata.\u003c/p\u003e\n\u003cdiv class=\"markdown-heading\" dir=\"auto\"\u003e\u003ch5 tabindex=\"-1\" class=\"heading-element\" dir=\"auto\"\u003ePeer to Peer transfer\u003c/h5\u003e\u003ca id=\"user-content-peer-to-peer-transfer\" class=\"anchor\" aria-label=\"Permalink: Peer to Peer transfer\" href=\"#peer-to-peer-transfer\"\u003e\u003csvg class=\"octicon octicon-link\" viewBox=\"0 0 16 16\" version=\"1.1\" width=\"16\" height=\"16\" aria-hidden=\"true\"\u003e\u003cpath d=\"m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z\"\u003e\u003c/path\u003e\u003c/svg\u003e\u003c/a\u003e\u003c/div\u003e\n\u003cp dir=\"auto\"\u003eDiscussion has started here: \u003ca href=\"https://docs.google.com/document/d/1rYDpSpJiQWmCQy8Cuiaa3NH-Co33oK_SC9HeXYo87QA/edit\" rel=\"nofollow\"\u003ehttps://docs.google.com/document/d/1rYDpSpJiQWmCQy8Cuiaa3NH-Co33oK_SC9HeXYo87QA/edit\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"markdown-heading\" dir=\"auto\"\u003e\u003ch5 tabindex=\"-1\" class=\"heading-element\" dir=\"auto\"\u003eIndexing, Search and Discovery\u003c/h5\u003e\u003ca id=\"user-content-indexing-search-and-discovery\" class=\"anchor\" aria-label=\"Permalink: Indexing, Search and Discovery\" href=\"#indexing-search-and-discovery\"\u003e\u003csvg class=\"octicon octicon-link\" viewBox=\"0 0 16 16\" version=\"1.1\" width=\"16\" height=\"16\" aria-hidden=\"true\"\u003e\u003cpath d=\"m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z\"\u003e\u003c/path\u003e\u003c/svg\u003e\u003c/a\u003e\u003c/div\u003e\n\u003cp dir=\"auto\"\u003eThe original registry provided some implementation of search for use with\nprivate registries. Support has been elided from V2 since we'd like to both\ndecouple search functionality from the registry. The makes the registry\nsimpler to deploy, especially in use cases where search is not needed, and\nlet's us decouple the image format from the registry.\u003c/p\u003e\n\u003cp dir=\"auto\"\u003eThere are explorations into using the catalog API and notification system to\nbuild external indexes. The current line of thought is that we will define a\ncommon search API to index and query docker images. Such a system could be run\nas a companion to a registry or set of registries to power discovery.\u003c/p\u003e\n\u003cp dir=\"auto\"\u003eThe main issue with search and discovery is that there are so many ways to\naccomplish it. There are two aspects to this project. The first is deciding on\nhow it will be done, including an API definition that can work with changing\ndata formats. The second is the process of integrating with \u003ccode\u003edocker search\u003c/code\u003e.\nWe expect that someone attempts to address the problem with the existing tools\nand propose it as a standard search API or uses it to inform a standardization\nprocess. Once this has been explored, we integrate with the docker client.\u003c/p\u003e\n\u003cp dir=\"auto\"\u003ePlease see the following for more detail:\u003c/p\u003e\n\u003cul dir=\"auto\"\u003e\n\u003cli\u003e\u003ca class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"58975220\" data-permission-text=\"Title is private\" data-url=\"https://github.com/distribution/distribution/issues/206\" data-hovercard-type=\"issue\" data-hovercard-url=\"/distribution/distribution/issues/206/hovercard\" href=\"https://github.com/distribution/distribution/issues/206\"\u003edistribution#206\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cdiv class=\"markdown-heading\" dir=\"auto\"\u003e\u003ch5 tabindex=\"-1\" class=\"heading-element\" dir=\"auto\"\u003eDeletes\u003c/h5\u003e\u003ca id=\"user-content-deletes\" class=\"anchor\" aria-label=\"Permalink: Deletes\" href=\"#deletes\"\u003e\u003csvg class=\"octicon octicon-link\" viewBox=\"0 0 16 16\" version=\"1.1\" width=\"16\" height=\"16\" aria-hidden=\"true\"\u003e\u003cpath d=\"m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z\"\u003e\u003c/path\u003e\u003c/svg\u003e\u003c/a\u003e\u003c/div\u003e\n\u003cblockquote\u003e\n\u003cp dir=\"auto\"\u003e\u003cstrong\u003eNOTE:\u003c/strong\u003e Deletes are a much asked for feature. Before requesting this\nfeature or participating in discussion, we ask that you read this section in\nfull and understand the problems behind deletes.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp dir=\"auto\"\u003eWhile, at first glance, implementing deleting seems simple, there are a number\nmitigating factors that make many solutions not ideal or even pathological in\nthe context of a registry. The following paragraph discuss the background and\napproaches that could be applied to arrive at a solution.\u003c/p\u003e\n\u003cp dir=\"auto\"\u003eThe goal of deletes in any system is to remove unused or unneeded data. Only\ndata requested for deletion should be removed and no other data. Removing\nunintended data is worse than \u003cem\u003enot\u003c/em\u003e removing data that was requested for\nremoval but ideally, both are supported. Generally, according to this rule, we\nerr on holding data longer than needed, ensuring that it is only removed when\nwe can be certain that it can be removed. With the current behavior, we opt to\nhold onto the data forever, ensuring that data cannot be incorrectly removed.\u003c/p\u003e\n\u003cp dir=\"auto\"\u003eTo understand the problems with implementing deletes, one must understand the\ndata model. All registry data is stored in a filesystem layout, implemented on\na \"storage driver\", effectively a \u003cem\u003evirtual file system\u003c/em\u003e (VFS). The storage\nsystem must assume that this VFS layer will be eventually consistent and has\npoor read- after-write consistency, since this is the lower common denominator\namon
6DC5
g the storage drivers. This is mitigated by writing values in reverse-\ndependent order, but makes wider transactional operations unsafe.\u003c/p\u003e\n\u003cp dir=\"auto\"\u003eLayered on the VFS model is a content-addressable \u003cem\u003edirected, acyclic graph\u003c/em\u003e\n(DAG) made up of blobs. Manifests reference layers. Tags reference manifests.\nSince the same data can be referenced by multiple manifests, we only store\ndata once, even if it is in different repositories. Thus, we have a set of\nblobs, referenced by tags and manifests. If we want to delete a blob we need\nto be certain that it is no longer referenced by another manifest or tag. When\nwe delete a manifest, we also can try to delete the referenced blobs. Deciding\nwhether or not a blob has an active reference is the crux of the problem.\u003c/p\u003e\n\u003cp dir=\"auto\"\u003eConceptually, deleting a manifest and its resources is quite simple. Just find\nall the manifests, enumerate the referenced blobs and delete the blobs not in\nthat set. An astute observer will recognize this as a garbage collection\nproblem. As with garbage collection in programming languages, this is very\nsimple when one always has a consistent view. When one adds parallelism and an\ninconsistent view of data, it becomes very challenging.\u003c/p\u003e\n\u003cp dir=\"auto\"\u003eA simple example can demonstrate this. Let's say we are deleting a manifest\n\u003cem\u003eA\u003c/em\u003e in one process. We scan the manifest and decide that all the blobs are\nready for deletion. Concurrently, we have another process accepting a new\nmanifest \u003cem\u003eB\u003c/em\u003e referencing one or more blobs from the manifest \u003cem\u003eA\u003c/em\u003e. Manifest \u003cem\u003eB\u003c/em\u003e\nis accepted and all the blobs are considered present, so the operation\nproceeds. The original process then deletes the referenced blobs, assuming\nthey were unreferenced. The manifest \u003cem\u003eB\u003c/em\u003e, which we thought had all of its data\npresent, can no longer be served by the registry, since the dependent data has\nbeen deleted.\u003c/p\u003e\n\u003cp dir=\"auto\"\u003eDeleting data from the registry safely requires some way to coordinate this\noperation. The following approaches are being considered:\u003c/p\u003e\n\u003cul dir=\"auto\"\u003e\n\u003cli\u003e\u003cem\u003eReference Counting\u003c/em\u003e - Maintain a count of references to each blob. This is\nchallenging for a number of reasons: 1. maintaining a consistent consensus\nof reference counts across a set of Registries and 2. Building the initial\nlist of reference counts for an existing registry. These challenges can be\nmet with a consensus protocol like Paxos or Raft in the first case and a\nnecessary but simple scan in the second..\u003c/li\u003e\n\u003cli\u003e\u003cem\u003eLock the World GC\u003c/em\u003e - Halt all writes to the data store. Walk the data store\nand find all blob references. Delete all unreferenced blobs. This approach\nis very simple but requires disabling writes for a period of time while the\nservice reads all data. This is slow and expensive but very accurate and\neffective.\u003c/li\u003e\n\u003cli\u003e\u003cem\u003eGenerational GC\u003c/em\u003e - Do something similar to above but instead of blocking\nwrites, writes are sent to another storage backend while reads are broadcast\nto the new and old backends. GC is then performed on the read-only portion.\nBecause writes land in the new backend, the data in the read-only section\ncan be safely deleted. The main drawbacks of this approach are complexity\nand coordination.\u003c/li\u003e\n\u003cli\u003e\u003cem\u003eCentralized Oracle\u003c/em\u003e - Using a centralized, transactional database, we can\nknow exactly which data is referenced at any given time. This avoids\ncoordination problem by managing this data in a single location. We trade\noff metadata scalability for simplicity and performance. This is a very good\noption for most registry deployments. This would create a bottleneck for\nregistry metadata. However, metadata is generally not the main bottleneck\nwhen serving images.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp dir=\"auto\"\u003ePlease let us know if other solutions exist that we have yet to enumerate.\nNote that for any approach, implementation is a massive consideration. For\nexample, a mark-sweep based solution may seem simple but the amount of work in\ncoordination offset the extra work it might take to build a \u003cem\u003eCentralized\nOracle\u003c/em\u003e. We'll accept proposals for any solution but please coordinate with us\nbefore dropping code.\u003c/p\u003e\n\u003cp dir=\"auto\"\u003eAt this time, we have traded off simplicity and ease of deployment for disk\nspace. Simplicity and ease of deployment tend to reduce developer involvement,\nwhich is currently the most expensive resource in software engineering. Taking\non any solution for deletes will greatly effect these factors, trading off\nvery cheap disk space for a complex deployment and operational story.\u003c/p\u003e\n\u003cp dir=\"auto\"\u003ePlease see the following issues for more detail:\u003c/p\u003e\n\u003cul dir=\"auto\"\u003e\n\u003cli\u003e\u003ca class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"70283693\" data-permission-text=\"Title is private\" data-url=\"https://github.com/distribution/distribution/issues/422\" data-hovercard-type=\"issue\" data-hovercard-url=\"/distribution/distribution/issues/422/hovercard\" href=\"https://github.com/distribution/distribution/issues/422\"\u003edistribution#422\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"71680345\" data-permission-text=\"Title is private\" data-url=\"https://github.com/distribution/distribution/issues/461\" data-hovercard-type=\"issue\" data-hovercard-url=\"/distribution/distribution/issues/461/hovercard\" href=\"https://github.com/distribution/distribution/issues/461\"\u003edistribution#461\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"71681036\" data-permission-text=\"Title is private\" data-url=\"https://github.com/distribution/distribution/issues/462\" data-hovercard-type=\"issue\" data-hovercard-url=\"/distribution/distribution/issues/462/hovercard\" href=\"https://github.com/distribution/distribution/issues/462\"\u003edistribution#462\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cdiv class=\"markdown-heading\" dir=\"auto\"\u003e\u003ch3 tabindex=\"-1\" class=\"heading-element\" dir=\"auto\"\u003eDistribution Package\u003c/h3\u003e\u003ca id=\"user-content-distribution-package\" class=\"anchor\" aria-label=\"Permalink: Distribution Package\" href=\"#distribution-package\"\u003e\u003csvg class=\"octicon octicon-link\" viewBox=\"0 0 16 16\" version=\"1.1\" width=\"16\" height=\"16\" aria-hidden=\"true\"\u003e\u003cpath d=\"m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z\"\u003e\u003c/path\u003e\u003c/svg\u003e\u003c/a\u003e\u003c/div\u003e\n\u003cp dir=\"auto\"\u003eAt its core, the Distribution Project is a set of Go packages that make up\nDistribution Components. At this time, most of these packages make up the\nRegistry implementation.\u003c/p\u003e\n\u003cp dir=\"auto\"\u003eThe package itself is considered unstable. If you're using it, please take care to vendor the dependent version.\u003c/p\u003e\n\u003cp dir=\"auto\"\u003eFor feature additions, please see the Registry section. In the future, we may break out a\nseparate Roadmap for distribution-specific features that apply to more than\njust the registry.\u003c/p\u003e\n\u003chr\u003e\n\u003cdiv class=\"markdown-heading\" dir=\"auto\"\u003e\u003ch3 tabindex=\"-1\" class=\"heading-element\" dir=\"auto\"\u003eProject Planning\u003c/h3\u003e\u003ca id=\"user-content-project-planning\" class=\"anchor\" aria-label=\"Permalink: Project Planning\" href=\"#project-planning\"\u003e\u003csvg class=\"octicon octicon-link\" viewBox=\"0 0 16 16\" version=\"1.1\" width=\"16\" height=\"16\" aria-hidden=\"true\"\u003e\u003cpath d=\"m7.775 3.275 1.25-1.25a3.5 3.5 0 1 1 4.95 4.95l-2.5 2.5a3.5 3.5 0 0 1-4.95 0 .751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018 1.998 1.998 0 0 0 2.83 0l2.5-2.5a2.002 2.002 0 0 0-2.83-2.83l-1.25 1.25a.751.751 0 0 1-1.042-.018.751.751 0 0 1-.018-1.042Zm-4.69 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042l-1.25 1.25a3.5 3.5 0 1 1-4.95-4.95l2.5-2.5a3.5 3.5 0 0 1 4.95 0 .751.751 0 0 1-.018 1.042.751.751 0 0 1-1.042.018 1.998 1.998 0 0 0-2.83 0l-2.5 2.5a1.998 1.998 0 0 0 0 2.83Z\"\u003e\u003c/path\u003e\u003c/svg\u003e\u003c/a\u003e\u003c/div\u003e\n\u003cp dir=\"auto\"\u003eAn \u003ca href=\"https://github.com/docker/distribution/wiki/Open-Source-Planning-Process\"\u003eOpen-Source Planning Process\u003c/a\u003e is used to define the Roadmap. \u003ca href=\"https://github.com/docker/distribution/wiki\"\u003eProject Pages\u003c/a\u003e define the goals for each Milestone and identify current progress.\u003c/p\u003e\n\u003c/article\u003e","renderedFileInfo":null,"shortPath":null,"symbolsEnabled":true,"tabSize":8,"topBannersInfo":{"overridingGlobalFundingFile":false,"globalPreferredFundingPath":null,"showInvalidCitationWarning":false,"citationHelpUrl":"https://docs.github.com/github/creating-cloning-and-archiving-repositories/creating-a-repository-on-github/about-citation-files","actionsOnboardingTip":null},"truncated":false,"viewable":true,"workflowRedirectUrl":null,"symbols":{"timed_out":false,"not_analyzed":false,"symbols":[{"name":"Roadmap","kind":"section_1","ident_start":2,"ident_end":9,"extent_start":0,"extent_end":13439,"fully_qualified_name":"Roadmap","ident_utf16":{"start":{"line_number":0,"utf16_col":2},"end":{"line_number":0,"utf16_col":9}},"extent_utf16":{"start":{"line_number":0,"utf16_col":0},"end":{"line_number":267,"utf16_col":0}}},{"name":"Distribution Goals","kind":"section_2","ident_start":589,"ident_end":607,"extent_start":586,"extent_end":997,"fully_qualified_name":"Distribution Goals","ident_utf16":{"start":{"line_number":14,"utf16_col":3},"end":{"line_number":14,"utf16_col":21}},"extent_utf16":{"start":{"line_number":14,"utf16_col":0},"end":{"line_number":24,"utf16_col":0}}},{"name":"Distribution Components","kind":"section_2","ident_start":1000,"ident_end":1023,"extent_start":997,"extent_end":13439,"fully_qualified_name":"Distribution Components","ident_utf16":{"start":{"line_number":24,"utf16_col":3},"end":{"line_number":24,"utf16_col":26}},"extent_utf16":{"start":{"line_number":24,"utf16_col":0},"end":{"line_number":267,"utf16_col":0}}},{"name":"Registry","kind":"section_3","ident_start":1423,"ident_end":1431,"extent_start":1419,"extent_end":12640,"fully_qualified_name":"Registry","ident_utf16":{"start":{"line_number":36,"utf16_col":4},"end":{"line_number":36,"utf16_col":12}},"extent_utf16":{"start":{"line_number":36,"utf16_col":0},"end":{"line_number":249,"utf16_col":0}}},{"name":"Data Storage and Distribution First","kind":"section_4","ident_start":1951,"ident_end":1986,"extent_start":1946,"extent_end":2378,"fully_qualified_name":"Data Storage and Distribution First","ident_utf16":{"start":{"line_number":48,"utf16_col":5},"end":{"line_number":48,"utf16_col":40}},"extent_utf16":{"start":{"line_number":48,"utf16_col":0},"end":{"line_number":58,"utf16_col":0}}},{"name":"Content Addressability","kind":"section_4","ident_start":2383,"ident_end":2405,"extent_start":2378,"extent_end":2636,"fully_qualified_name":"Content Addressability","ident_utf16":{"start":{"line_number":58,"utf16_col":5},"end":{"line_number":58,"utf16_col":27}},"extent_utf16":{"start":{"line_number":58,"utf16_col":0},"end":{"line_number":64,"utf16_col":0}}},{"name":"Content Agnostic","kind":"section_4","ident_start":2641,"ident_end":2657,"extent_start":2636,"extent_end":3331,"fully_qualified_name":"Content Agnostic","ident_utf16":{"start":{"line_number":64,"utf16_col":5},"end":{"line_number":64,"utf16_col":21}},"extent_utf16":{"start":{"line_number":64,"utf16_col":0},"end":{"line_number":77,"utf16_col":0}}},{"name":"Simplicity","kind":"section_4","ident_start":3336,"ident_end":3346,"extent_start":3331,"extent_end":3735,"fully_qualified_name":"Simplicity","ident_utf16":{"start":{"line_number":77,"utf16_col":5},"end":{"line_number":77,"utf16_col":15}},"extent_utf16":{"start":{"line_number":77,"utf16_col":0},"end":{"line_number":87,"utf16_col":0}}},{"name":"Extensibility","kind":"section_4","ident_start":3740,"ident_end":3753,"extent_start":3735,"extent_end":4090,"fully_qualified_name":"Extensibility","ident_utf16":{"start":{"line_number":87,"utf16_col":5},"end":{"line_number":87,"utf16_col":18}},"extent_utf16":{"start":{"line_number":87,"utf16_col":0},"end":{"line_number":96,"utf16_col":0}}},{"name":"Active Feature Discussions","kind":"section_4","ident_start":4095,"ident_end":4121,"extent_start":4090,"extent_end":12640,"fully_qualified_name":"Active Feature Discussions","ident_utf16":{"start":{"line_number":96,"utf16_col":5},"end":{"line_number":96,"utf16_col":31}},"extent_utf16":{"start":{"line_number":96,"utf16_col":0},"end":{"line_number":249,"utf16_col":0}}},{"name":"Proxying to other Registries","kind":"section_5","ident_start":4450,"ident_end":4478,"extent_start":4444,"extent_end":4748,"fully_qualified_name":"Proxying to other Registries","ident_utf16":{"start":{"line_number":105,"utf16_col":6},"end":{"line_number":105,"utf16_col":34}},"extent_utf16":{"start":{"line_number":105,"utf16_col":0},"end":{"line_number":112,"utf16_col":0}}},{"name":"Metadata storage","kind":"section_5","ident_start":4754,"ident_end":4770,"extent_start":4748,"extent_end":5149,"fully_qualified_name":"Metadata storage","ident_utf16":{"start":{"line_number":112,"utf16_col":6},"end":{"line_number":112,"utf16_col":22}},"extent_utf16":{"start":{"line_number":112,"utf16_col":0},"end":{"line_number":120,"utf16_col":0}}},{"name":"Peer to Peer transfer","kind":"section_5","ident_start":5155,"ident_end":5176,"extent_start":5149,"extent_end":5293,"fully_qualified_name":"Peer to Peer transfer","ident_utf16":{"start":{"line_number":120,"utf16_col":6},"end":{"line_number":120,"utf16_col":27}},"extent_utf16":{"start":{"line_number":120,"utf16_col":0},"end":{"line_number":124,"utf16_col":0}}},{"name":"Indexing, Search and Discovery","kind":"section_5","ident_start":5299,"ident_end":5329,"extent_start":5293,"extent_end":6625,"fully_qualified_name":"Indexing, Search and Discovery","ident_utf16":{"start":{"line_number":124,"utf16_col":6},"end":{"line_number":124,"utf16_col":36}},"extent_utf16":{"start":{"line_number":124,"utf16_col":0},"end":{"line_number":149,"utf16_col":0}}},{"name":"Deletes","kind":"section_5","ident_start":6631,"ident_end":6638,"extent_start":6625,"extent_end":12640,"fully_qualified_name":"Deletes","ident_utf16":{"start":{"line_number":149,"utf16_col":6},"end":{"line_number":149,"utf16_col":13}},"extent_utf16":{"start":{"line_number":149,"utf16_col":0},"end":{"line_number":249,"utf16_col":0}}},{"name":"Distribution Package","kind":"section_3","ident_start":12644,"ident_end":12664,"extent_start":12640,"extent_end":13149,"fully_qualified_name":"Distribution Package","ident_utf16":{"start":{"line_number":249,"utf16_col":4},"end":{"line_number":249,"utf16_col":24}},"extent_utf16":{"start":{"line_number":249,"utf16_col":0},"end":{"line_number":263,"utf16_col":0}}},{"name":"Project Planning","kind":"section_3","ident_start":13153,"ident_end":13169,"extent_start":13149,"extent_end":13439,"fully_qualified_name":"Project Planning","ident_utf16":{"start":{"line_number":263,"utf16_col":4},"end":{"line_number":263,"utf16_col":20}},"extent_utf16":{"start":{"line_number":263,"utf16_col":0},"end":{"line_number":267,"utf16_col":0}}}]}},"copilotInfo":null,"copilotAccessAllowed":false,"modelsAccessAllowed":false,"modelsRepoIntegrationEnabled":false,"csrf_tokens":{"/jimmyyan/distribution/branches":{"post":"Mt2vYVNfiqaNQE9zQwg_C6JwUHUCV4qOIltCHAhIZO2R3EGfGVLXbHz3BbzJ4rp9jXdvSVL0amHMVrLRxS_puA"},"/repos/preferences":{"post":"W9_90CFgM2IPgNxWHru0OSYI1f5XliUYsLh8iNpWGfmMBdnVoMXpYJgPbqkEFyfeIbZooRZIp5LJxeS8V2A2Wg"}}},"title":"distribution/ROADMAP.md at master · jimmyyan/distribution","appPayload":{"helpUrl":"https://docs.github.com","findFileWorkerPath":"/assets-cdn/worker/find-file-worker-7d7eb7c71814.js","findInFileWorkerPath":"/assets-cdn/worker/find-in-file-worker-1ae9fa256942.js","githubDevUrl":null,"enabled_features":{"code_nav_ui_events":false,"react_blob_overlay":false,"accessible_code_button":true,"github_models_repo_integration":false}}}