registry does not get cleaned up after disabling Registry for the project

Summary + Steps to reproduce

If you disable registry feature for a project and then use /opt/gitlab/embedded/bin/registry garbage-collect --dry-run=false /var/opt/gitlab/registry/config.yml the data will not get deleted. you can still enable the registry feature on the same project and the data is there again.

Expected behavior

After garbage collecting the registry it should also remove data from projects where the registry is disabled. Maybe add a warning to the registry-feature-checkbox that people know this can be dangerous. Maybe you could also add a button near the registry-feature-checkbox of the project that says "Delete all images of this project" if you don't like the automatic deletion.

Actual behavior

At the moment the docker images will never get deleted if you disable the feature. You cannot access the data but it is still using space.

@ayufan When the registry is disabled for a particular project should the associated images be swept up to clear the space?

Added ~19173 ~343072 ~14213 labels

The data after disabling is not removed. The only way to clean up the data is to delete project.

I have a curiosity similar to this. If an image is overwritten (for example latest) does the garbage collection handle cleanup of what is not longer reachable there as well or is it only recovered after project deletion. We currently build our images for deployment and when we build a new latest image the registry size seems to climb significantly over time.

@lukehowell Currently registry storage can only grow. You can use imperfect omnibus-gitlab#1409 (closed), but we are working on solution that would allow to make Container Registry in good shape over time.

mentioned in issue omnibus-gitlab#1409 (closed)

marked this issue as related to #18525 (moved)

Hi,

First of all, thank you for raising an issue to help improve the GitLab product. This issue was labelled as a ~"feature proposal" in the past. In order to maintain order in the issue tracker, we are starting to close off old, unpopular feature proposals that have not gained many votes since opening.

This issue will be marked for closure, as it meets the following criteria:

• Created over 1 year ago
• Labelled as a ~"feature proposal"
• Unscheduled (not associated with a milestone)
• Less than 10 upvotes

Thanks for your help and please raise any new feature proposals as a new issue.

/cc @markglenfletcher

added auto updated awaiting feedback labels

We are reverting the above policy regarding old, feature proposals until we find a better solution. Sorry for the noise.

The issue will no longer be marked for closure.

removed auto updated awaiting feedback labels

added devopspackage label

added 1 deleted label and removed 1 deleted label

added Category:Container Registry label

changed milestone to %Backlog

added [deprecated] Accepting merge requests label

added grouppackage registry label

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue