Skip to content

Conversation

@natefive
Copy link

@natefive natefive commented Apr 17, 2023

This PR enables volatile overlayfs mounts following the same implementation as #4785

  • Updates the code inline with surrounding code changes since the PR was originally proposed
  • Fixes a comment typo 'ommit' to 'omit' as raised on the original PR
  • Add a SupportsVolatileMount func in overlayutils to test if volatile mounts are available from the NewSnapshotter func

@rata

@k8s-ci-robot
Copy link

Hi @natefive. Thanks for your PR.

I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@natefive natefive force-pushed the volatile_mounts_global_option branch 2 times, most recently from 3114067 to dfbd2a7 Compare April 18, 2023 10:24
@natefive natefive force-pushed the volatile_mounts_global_option branch from dfbd2a7 to 0f42f4d Compare April 18, 2023 16:16
@natefive natefive changed the title Draft: Add support for overlay volatile option Add support for overlay volatile option Apr 18, 2023
@fuweid fuweid self-requested a review April 20, 2023 05:28
@natefive
Copy link
Author

any thoughts @fuweid :)?

}
}()

// The volatile option of overlayfs doesn't allow to mount again using the
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we should change the option here. If there is conflict, we should modify the option before call the WithTempMount, for instance, https://github.com/containerd/containerd/pull/8259/files.

Copy link
Author

Choose a reason for hiding this comment

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

there are lots of calls to WithTempMount? should I create another function which modifies the options calls before calling WithTempMount then update those other calls to call the new function? Feels like pointless nesting maybe I am misunderstanding, would be helpful if that link has some line numbers :) ty

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 this is probably the right place to strip the option. Need to ensure the input mount array is not overwritten though.

Copy link
Member

Choose a reason for hiding this comment

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

@natefive Sorry for late reply.

should I create another function which modifies the options calls before calling WithTempMount then update those other calls to call the new function?

For my original comment, yes. But recently, I checked the code about starting container. It's unlikely to change the mount since there is no entrypoint for us to update it before passing to shim.

containerd/container.go

Lines 244 to 267 in b6abda7

s, err := c.client.getSnapshotter(ctx, r.Snapshotter)
if err != nil {
return nil, err
}
mounts, err := s.Mounts(ctx, r.SnapshotKey)
if err != nil {
return nil, err
}
spec, err := c.Spec(ctx)
if err != nil {
return nil, err
}
for _, m := range mounts {
if spec.Linux != nil && spec.Linux.MountLabel != "" {
if ml := label.FormatMountLabel("", spec.Linux.MountLabel); ml != "" {
m.Options = append(m.Options, ml)
}
}
request.Rootfs = append(request.Rootfs, &types.Mount{
Type: m.Type,
Source: m.Source,
Target: m.Target,
Options: m.Options,
})

I think we should introduce a label like #6528.

Maybe we don't need to persist the label in boltdb. We can pass the label by gRPC context and get mount with the option when we want to get the mount.

cc @dmcgowan

}

if o.volatile {
options = append(options, "volatile")
Copy link
Member

Choose a reason for hiding this comment

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

overlayfs snapshot is service and this option is global setting. I think there are existing cases which required the rootfs is synced after umount. Currently, the kubernetes container is temporary and we can't restart a exited container. kubernetes always recreates container for pod. So, I would like to add the volatile option from caller, for example, CRI plugin.

I was thinking that we can go in this way:

a. When the overlayfs snapshot inits, it use SupportsVolatileMount to check and add the capability in Meta.

InitFn: func(ic *plugin.InitContext) (interface{}, error) {
ic.Meta.Platforms = append(ic.Meta.Platforms, platforms.DefaultSpec())
config, ok := ic.Config.(*Config)
if !ok {
return nil, errors.New("invalid overlay configuration")
}
root := ic.Root
if config.RootPath != "" {
root = config.RootPath
}
var oOpts []overlay.Opt
if config.UpperdirLabel {
oOpts = append(oOpts, overlay.WithUpperdirLabel)
}
ic.Meta.Exports["root"] = root
return overlay.NewSnapshotter(root, append(oOpts, overlay.AsynchronousRemove)...)
},

b. Add the mount option to add volatile if snapshot has the capability. Currently, the CRI UserNS feature is working with capability. You can check the main branch for this. And just in case, we should add CRI option to turn this feature on.

@dmcgowan dmcgowan added the status/needs-discussion Needs discussion and decision from maintainers label Jun 6, 2023
@mcginne
Copy link

mcginne commented Oct 24, 2023

Hi folks, do we have any path or outlook on when this could get merged? We see significantly better IO performance on RedHat/CRIO based systems which already have the volatile option support, and would like to get the same on containerd systems.

@k8s-ci-robot
Copy link

PR needs rebase.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@github-actions
Copy link

This PR is stale because it has been open 90 days with no activity. This PR will be closed in 7 days unless new comments are made or the stale label is removed.

@github-actions github-actions bot added the Stale label Mar 10, 2024
@github-actions
Copy link

This PR was closed because it has been stalled for 7 days with no activity.

@github-actions github-actions bot closed this Mar 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

needs-ok-to-test needs-rebase Stale status/needs-discussion Needs discussion and decision from maintainers

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants