-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add: no namespace remove snapshot support to demux snapshotter #678
add: no namespace remove snapshot support to demux snapshotter #678
Conversation
We now see remove content messages being sent to the in-VM snapshotters and cleanup scheduled. The errors below should be further reduced by cache eviction feature #651 which is currently in draft #662 slowed by test issues.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@@ -158,6 +158,12 @@ func (s *Snapshotter) Commit(ctx context.Context, name string, key string, opts | |||
func (s *Snapshotter) Remove(ctx context.Context, key string) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would we implement other APIs that aren't in the Snapshotter interface? Treating ""
as a special "delete all" operation seems scary to be honest. If we would have different APIs in future, we should move these CleanupAll and DeteleAll there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the xxxAll
functions might be poorly named here. These are implemented on the cache
and we just want to execute Remove
on all cached snapshotter entries. In other words, broadcast the Remove
or Cleanup
request to all cached snapshotters. In theory a snapshot could be in use by multiple VMs and only available for free in a subset, but the remote snapshotter should be able to handle that case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would BroadcastRemove
be more clear than RemoveAll
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RemoveAll is fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If someone forget to set the namespace, we are not only deleting a VM's snapshot, but also all of VMs' snapshot. This seems dangerous to me.
That being said, I don't have better alternatives.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The least I can do is to have a configuration option for enabling garbage collection via these broadcasts. So users would explicitly accept risk of enabling the feature and then forgetting to set the namespace would be user error. Also I have committed to some documentation for the demux snapshotter so that would outline the risk.
Signed-off-by: Austin Vazquez <[email protected]>
What is the use-case for non-namespaced |
That's exactly correct. So containerd appears to do a non-namespaced walk followed by removes after a layer removal for garbage collection based on observations. I'm sure that is an oversimplification. |
After conversation with @kzys, decided to close this PR and open an issue discussing potential paths forward with support garbage collection with remote snapshotters. Stay tuned. |
Signed-off-by: Austin Vazquez [email protected]
Issue #, if available:
#652
Description of changes:
Add feature to demux snapshotter to broadcast snapshot removal and cleanup to all cached snapshotters if no namespace is provided.
Because of the broadcast, we need to mask snapshot not found errors as most snapshotters are unlikely to have the referenced snapshot.
Reworked internal snapshotter mocks into a single more robust snapshotter mock.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.