Skip to content
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

overlay: fallback without data only layers #2112

Conversation

giuseppe
Copy link
Member

if the overlay data only layers feature is not available, then use a regular overlay lower layer.

The same functionality is already present in the mount helper for composefs.

if the overlay data only layers feature is not available, then use a
regular overlay lower layer.

The same functionality is already present in the mount helper for
composefs.

Signed-off-by: Giuseppe Scrivano <[email protected]>
@giuseppe giuseppe added the area/composefs composefs related changes label Sep 26, 2024
@@ -271,6 +272,18 @@ func (d *Driver) getSupportsVolatile() (bool, error) {
return supportsVolatile, nil
}

func (d *Driver) getSupportsDataOnly() (bool, error) {
Copy link
Member

Choose a reason for hiding this comment

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

nit: getSupportsDataOnly->supportsDataOnly

Copy link
Member Author

Choose a reason for hiding this comment

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

we already have a supportsDataOnly *bool in the Driver struct

@kwilczynski
Copy link
Member

@kwilczynski
Copy link
Member

@giuseppe, would it be possible to expose this as a warning or a small helper so that users such as CRI-O could want the user that composefs is working in a degraded or unsupported (or not fully supported?) mode? We will users that might not have the kernel feature ready or backported for a while...

Unless you think handling this transparently is good enough.

@cgwalters
Copy link
Contributor

Is there any reason we need to reimplement the mount logic here versus just calling out to mount.composefs? That would also ensure we automatically pick up other things like containers/composefs@91a3047 (cosmetic, but useful imo).

Copy link
Contributor

openshift-ci bot commented Sep 27, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cgwalters, giuseppe

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@cgwalters
Copy link
Contributor

/lgtm

@openshift-ci openshift-ci bot added the lgtm label Sep 27, 2024
@openshift-merge-bot openshift-merge-bot bot merged commit 3eafe4c into containers:main Sep 27, 2024
19 checks passed
@giuseppe
Copy link
Member Author

Is there any reason we need to reimplement the mount logic here versus just calling out to mount.composefs? That would also ensure we automatically pick up other things like containers/composefs@91a3047 (cosmetic, but useful imo).

we are using a single overlay mount on top of multiple erofs mounts and basedirs, so there is not a single IMAGE

@cgwalters
Copy link
Contributor

Ah right, so this relates to #2018

@kwilczynski
Copy link
Member

For posterity:

This fixes an issue CRI-O had on platforms where the kernel lacked the required support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved area/composefs composefs related changes lgtm
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants