mirror of
https://github.com/distribution/distribution
synced 2024-11-06 19:35:52 +01:00
Remove outdated docs
This commit removes Registry v1 -> Registry v2 migration guide as Registry v1 was deprecated long time ago and is no long longer supported. We also remove some references to "Future" roadmap which are wildly outdated, too. Signed-off-by: Milos Gajdos <milosthegajdos@gmail.com>
This commit is contained in:
parent
88087f80ed
commit
0634160074
@ -1,28 +0,0 @@
|
||||
---
|
||||
published: false
|
||||
---
|
||||
|
||||
# Migrating a 1.0 registry to 2.0
|
||||
|
||||
TODO: This needs to be revised in light of Olivier's work
|
||||
|
||||
A few thoughts here:
|
||||
|
||||
There was no "1.0". There was an implementation of the Registry API V1 but only a version 0.9 of the service was released.
|
||||
The image formats are not compatible in any way. One must convert v1 images to v2 images using a docker client or other tool.
|
||||
One can migrate images from one version to the other by pulling images from the old registry and pushing them to the v2 registry.
|
||||
|
||||
-----
|
||||
|
||||
The Docker Registry 2.0 is backward compatible with images created by the earlier specification. If you are migrating a private registry to version 2.0, you should use the following process:
|
||||
|
||||
1. Configure and test a 2.0 registry image in a sandbox environment.
|
||||
|
||||
2. Back up up your production image storage.
|
||||
|
||||
Your production image storage should reside on a volume or storage backend.
|
||||
Make sure you have a backup of its contents.
|
||||
|
||||
3. Stop your existing registry service.
|
||||
|
||||
4. Restart your registry with your tested 2.0 image.
|
@ -52,19 +52,6 @@ specification, details of the protocol will be left to a future specification.
|
||||
Relevant header definitions and error codes are present to provide an
|
||||
indication of what a client may encounter.
|
||||
|
||||
#### Future
|
||||
|
||||
There are features that have been discussed during the process of cutting this
|
||||
specification. The following is an incomplete list:
|
||||
|
||||
- Immutable image references
|
||||
- Multiple architecture support
|
||||
- Migration from v2compatibility representation
|
||||
|
||||
These may represent features that are either out of the scope of this
|
||||
specification, the purview of another specification or have been deferred to a
|
||||
future version.
|
||||
|
||||
### Use Cases
|
||||
|
||||
For the most part, the use cases of the former registry API apply to the new
|
||||
|
@ -52,19 +52,6 @@ specification, details of the protocol will be left to a future specification.
|
||||
Relevant header definitions and error codes are present to provide an
|
||||
indication of what a client may encounter.
|
||||
|
||||
#### Future
|
||||
|
||||
There are features that have been discussed during the process of cutting this
|
||||
specification. The following is an incomplete list:
|
||||
|
||||
- Immutable image references
|
||||
- Multiple architecture support
|
||||
- Migration from v2compatibility representation
|
||||
|
||||
These may represent features that are either out of the scope of this
|
||||
specification, the purview of another specification or have been deferred to a
|
||||
future version.
|
||||
|
||||
### Use Cases
|
||||
|
||||
For the most part, the use cases of the former registry API apply to the new
|
||||
|
Loading…
Reference in New Issue
Block a user