Skip to content
This repository has been archived by the owner on Apr 17, 2023. It is now read-only.

Added support for removing images/tags #854

Merged
merged 4 commits into from
May 9, 2016
Merged

Conversation

mssola
Copy link
Collaborator

@mssola mssola commented May 3, 2016

Soft delete support has been supported in Docker Distribution since at least
2.1. This was not enough to implement the removal of images/tags in Portus
because there was no support to GC these soft deleted blobs. Since 2.4, it's
possible to not just delete the manifest, but also to GC blobs no longer
referenced by any image manifest. This means that after being able to track
digests, we can now safely provide image/tag removal support. For safety
concerns, tags with an empty digest will not be allowed to be removed (this
is more likely to be the case of Portus versions that have been running for
some time). In previous PRs this has already been addressed, so admins can
update their DB filling in the empty gaps (e.g. see PRs #825 or #830).

The main downside of this change is that there is no way for a client to detect
whether a remote registry supports GC. Because of this, a configuration option
has been provided, which is disabled by default. The rationale is that
administrators that are really sure about the availability of GC on their
private registry will have to enable it explicitly.

Fixes #197

Signed-off-by: Miquel Sabaté Solà msabate@suse.com

@mssola
Copy link
Collaborator Author

mssola commented May 3, 2016

Some screenshots:

Removing an image with tags:

removal-activities

After the previous screenshot, we push the same image back:

removal-images-push

The UI for removing images and tags:

delete-ui

Soft delete support has been supported in Docker Distribution since at least
2.1. This was not enough to implement the removal of images/tags in Portus
because there was no support to GC these soft deleted blobs. Since 2.4, it's
possible to not just delete the manifest, but also to GC blobs no longer
referenced by any image manifest. This means that after being able to track
digests, we can now safely provide image/tag removal support. For safety
concerns, tags with an empty digest will not be allowed to be removed (this
is more likely to be the case of Portus versions that have been running for
some time). In previous PRs this has already been addressed, so admins can
update their DB filling in the empty gaps (e.g. see PRs SUSE#825 or SUSE#830).

The main downside of this change is that there is no way for a client to detect
whether a remote registry supports GC. Because of this, a configuration option
has been provided, which is disabled by default. The rationale is that
administrators that are really sure about the availability of GC on their
private registry will have to enable it explicitly.

Fixes SUSE#197

Signed-off-by: Miquel Sabaté Solà <msabate@suse.com>
@@ -0,0 +1,14 @@
# DeleteEnabeld redirects the user back if delete support is not enabled. A
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo, should read DeleteEnabled.

@monstermunchkin
Copy link
Contributor

LGTM

Signed-off-by: Miquel Sabaté Solà <msabate@suse.com>
@mssola
Copy link
Collaborator Author

mssola commented May 4, 2016

Fixed typos pointed out by @monstermunchkin. I'll squash my commits once reviewing is over 😉

@@ -0,0 +1,14 @@
# DeleteEnabled redirects the user back if delete support is not enabled. A
# `before_action` will be created for the :destroy method.
module DeleteEnabled
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is some convention to name concerns like polymorph activerecord relations ending with able, e.g. Deletable

@tboerger
Copy link
Contributor

tboerger commented May 4, 2016

Beside my NITPICK LGTM

Signed-off-by: Miquel Sabaté Solà <msabate@suse.com>

# Delete this repository if all tags were successfully deleted.
if @repository.reload.tags.any?
redirect_to repository_path(@repository), alert: "Could not remove all the tags"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be useful to dump more information into Rails' log (like which tags could not have been deleted and eventually a reason). Otherwise an admin will have a hard time figuring this out on his own.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is logged, because it ends up calling Tag#delete_by_digest!, which logs any errors. Maybe I can provide an extra line of: "Error: tags [...] could not be removed" (the reason on why they have been removed is logged by Tag#delete_by_digest!)

@flavio
Copy link
Member

flavio commented May 6, 2016

It looks good to me.

A couple of considerations:

  • users will probably want to delete a namespace and all its contents. This will have an impact on the activity events we are currently creating.
  • this PR does the soft delete inside of the registry, the user has still to run the GC manually and we still have to add a maintenance mode for that. Am I right?

Signed-off-by: Miquel Sabaté Solà <msabate@suse.com>
@mssola
Copy link
Collaborator Author

mssola commented May 6, 2016

@flavio pushed a commit fixing your comments. I'll squash the commits once the review is over.

users will probably want to delete a namespace and all its contents. This will have an impact on the activity events we are currently creating

Yes. My plan is to do the same as I'm doing for removed images/tags: update the recipient and add stuff into the parameters attribute.

this PR does the soft delete inside of the registry, the user has still to run the GC manually and we still have to add a maintenance mode for that. Am I right?

Yes and no 😄. Yes, administrators are still required to call GC (this will be documented, and there's already a big fat explanation on the config. option about that). About maintenance mode... well, it's recommended but not enforced 😅. That is, you can run a GC operation without being in maintenance mode and the registry won't complain. However, if you do that, then there are race conditions. So, from the point of view of the registry, it's recommended but not enforced. This should also be in the documentation 😉

@flavio
Copy link
Member

flavio commented May 9, 2016

@flavio pushed a commit fixing your comments. I'll squash the commits once the review is over.

LGTM

users will probably want to delete a namespace and all its contents. This will have an impact on the activity events we are currently creating

Yes. My plan is to do the same as I'm doing for removed images/tags: update the recipient and add stuff into the parameters attribute.

Sounds good to me.

this PR does the soft delete inside of the registry, the user has still to run the GC manually and we still have to add a maintenance mode for that. Am I right?

Yes and no 😄. Yes, administrators are still required to call GC (this will be documented, and there's already a big fat explanation on the config. option about that). About maintenance mode... well, it's recommended but not enforced 😅. That is, you can run a GC operation without being in maintenance mode and the registry won't complain. However, if you do that, then there are race conditions. So, from the point of view of the registry, it's recommended but not enforced. This should also be in the documentation 😉

I'm fine with that as we discussed the ongoing plan about "remove all the things!"

@mssola mssola merged commit f757066 into SUSE:master May 9, 2016
@mssola mssola deleted the delete-ui branch May 9, 2016 10:45
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants