propose intelligent deletion management approach

[stevvooe]

Currently, deletes of content in the registry are allowed with administration privileges. This means layers and manifests can be deleted, with extreme prejudice. This meets most use cases where the goal is to remove old or unused layers. Unfortunately, this allows for one to corrupt a manifests by deleting dependent data. This is insufficient for integration into the docker client.

The registry API allows deletion of registry objects under various scenarios. The initial intent of the new registry implementation was to have deletes be integrated from the start. With the current state of the manifest specification, deletes were challenging to implement or impossible to implement reliably. Changes are occurring to address this in #62.

There are several aspects to this problem:

1. Most registry data has interdependencies that are expressed internally but they are expensive to resolve while underlying data is changing.
2. Deletes under eventual consistency results in odd scenarios that wouldn't be present in a transactional system. This fact needs to be considered.

We need to propose a solution that can allow for all proposed deletes in a reliable and safe manner.

[TomasTomecek]

Why is this closed?

[dmp42]

Soft delete have been implemented as part of the API, and more specialized issues have been opened for garbage collection.

[tunix]

@dmp42 does soft delete, delete only the repository records/data and not the actual files & folders on the disk? can we use soft delete atm?

[dmp42]

@tunix you should find info about it here: https://github.com/docker/distribution/blob/master/docs/spec/api.md#deleting-a-layer

Soft delete only delete references, and not the actual files.