Story #5179
closed
As a user I can recursively remove docker content units.
Status:
CLOSED - CURRENTRELEASE
Description
Workflow¶
Removal of docker content unit would allow removal of the content unit in question if no content unit on a higher level references it. If it can be removed, all (otherwise unused) content units on lower levels are removed recursively.
- When a docker image manifest is removed, all its blobs( not referenced by other image manifests) are removed as well. If docker manifest is referenced by tags, or by manifest lists, removal is not possible.
- When a docker manifest list is removed, all its manifests( not referenced by other manifests lists and not tagged) are removed as well. Furthermore, same story with the blobs. If docker manifest list is referenced by tags, removal is not possible unless force flag is specified.
- (Behavior change from pulp 2) When a tag is removed, all unreferenced content is also removed. If a tagged manifest/manifest_list has other tags or other references, only the tag is removed.
- Removal of blobs will not be possible unless it has no references.
Endpoint
POST v3/docker/recursive-remove content_hrefs=[] repo/repo_version=X
Notes
When removal is not possible because of higher level references, a list of _hrefs of those references will be returned along with the user friendly message.
- Description updated (diff)
- Subject changed from As a user I can remove and forcely remove docker content units. to As a user I can remove and forcefully remove docker content units.
- Description updated (diff)
- Description updated (diff)
Thanks for writing this up! I have just two comments:
- For the sake of completeness, we should specify what happens on blob removal. Proposal: without "force" it works analogously to the other artifact types, i.e. removal is not possible if any manifest refers to it. "force" is not supported for blobs(?) (I think this operation does not make much sense)
- For the regular case (not forced): If the removal of an artifact is not possible because there are references to the artifact, what information about these references do we give back to the caller? (no information at all, single reference that caused the error, all references that point to the artifact. I have no idea about the overhead created by these options)
Question
When we remove tag with force flag do we want to recursively remove content units on lower levels?
I think we don't. This functionality looks unrelated to "force". For all other artifact type "force" says "delete on higher levels as well". If there is a need for recursive delete for tags, I tend to introduce another flag for it.
gmbnomis wrote:
Thanks for writing this up! I have just two comments:
- For the sake of completeness, we should specify what happens on blob removal. Proposal: without "force" it works analogously to the other artifact types, i.e. removal is not possible if any manifest refers to it. "force" is not supported for blobs(?) (I think this operation does not make much sense)
Force flag will not be applicable for blobs. In general the plan is to disallow removal of blobs, unless they are orphans.
- For the regular case (not forced): If the removal of an artifact is not possible because there are references to the artifact, what information about these references do we give back to the caller? (no information at all, single reference that caused the error, all references that point to the artifact. I have no idea about the overhead created by these options)
Probably just the message that it is referenced in other manifests lists or that it has tags, therefore regular removal is not possible. Will it be useful to the user to see the list of digests the artifact is referenced in?
We can keep this in mind, and see that's the overhead whenever we get to the implementation.
Question
When we remove tag with force flag do we want to recursively remove content units on lower levels?
I think we don't. This functionality looks unrelated to "force". For all other artifact type "force" says "delete on higher levels as well". If there is a need for recursive delete for tags, I tend to introduce another flag for it.
ipanova@redhat.com wrote:
gmbnomis wrote:
- For the regular case (not forced): If the removal of an artifact is not possible because there are references to the artifact, what information about these references do we give back to the caller? (no information at all, single reference that caused the error, all references that point to the artifact. I have no idea about the overhead created by these options)
Probably just the message that it is referenced in other manifests lists or that it has tags, therefore regular removal is not possible. Will it be useful to the user to see the list of digests the artifact is referenced in?
I was thinking about returning the _href to the artifacts, not the digests. For example, I think this could help the user to make an informed decision whether repeating the removal with "force" is a sensible thing to do.
I agree, that makes sense to me.
- Description updated (diff)
- Subject changed from As a user I can remove and forcefully remove docker content units. to As a user I can recursively remove and forcefully remove docker content units.
- Description updated (diff)
- Description updated (diff)
- Related to Story #5232: As a user I can remove docker content units with a force flag added
- Subject changed from As a user I can recursively remove and forcefully remove docker content units. to As a user I can recursively remove docker content units.
- Description updated (diff)
- Description updated (diff)
- Groomed changed from No to Yes
- Status changed from NEW to ASSIGNED
- Assignee set to amacdona@redhat.com
- Status changed from ASSIGNED to POST
- Related to Story #5322: As a user I have retuned a list of references that prevent recursive removal added
- Sprint changed from Sprint 57 to Sprint 58
- Status changed from POST to MODIFIED
- % Done changed from 0 to 100
Applied in changeset commit:pulp_docker|b2d9900247a6bb8a83f44af05f7dffd66d7288dc.
- Project changed from Docker Support to Container Support
- Status changed from MODIFIED to CLOSED - CURRENTRELEASE
- Sprint/Milestone set to 1.0.0
Also available in: Atom
PDF
.
Recursively remove docker content.
https://pulp.plan.io/issues/5179 fixes #5179