buildah
buildah copied to clipboard
Add user configuration to buildah container image
What type of PR is this?
/kind bug
What this PR does / why we need it:
The container has configuration for root, this commit adds a similar configuration for the build user.
Closes: #4669
How to verify it
The commands displaying the configuration
podman run --rm quay.io/containers/buildah buildah info
podman run --rm --user build quay.io/containers/buildah buildah info
should both contain:
"GraphDriverName": "overlay",
"GraphOptions": [
"overlay.imagestore=/var/lib/shared",
"overlay.mount_program=/usr/bin/fuse-overlayfs",
"overlay.mountopt=nodev,fsync=0"
]
Which issue(s) this PR fixes:
Fixes #4669
Special notes for your reviewer:
Does this PR introduce a user-facing change?
None
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: nolange Once this PR has been reviewed and has the lgtm label, please assign cevich for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.
Approvers can indicate their approval by writing /approve
in a comment
Approvers can cancel approval by writing /approve cancel
in a comment
A lot of these settings are builtin to buildah and not needed.
You can also copy directly your storage.conf file into its final destination, as long as you wait for the build user to be added, I don't know why you are using the /tmp directory.
You are forcing the system to always use fuse-overlay, which is not always necessary for rootless containers and requires the /dev/fuse device to be added to the container.
@giuseppe PTAL
I agree we should not change the default, fuse-overlayfs must be a fallback when the native driver cannot be used
A lot of these settings are builtin to buildah and not needed.
See #4669, it fixes a real problem for me.
You can also copy directly your storage.conf file into its final destination, as long as you wait for the build user to be added, I don't know why you are using the /tmp directory.
Cause then I would need another step to fixup owner and permissions
You are forcing the system to always use fuse-overlay, which is not always necessary for rootless containers and requires the /dev/fuse device to be added to the container.
Its done the same way for the root user? Why is this only an argument for rootless?
I would prefer to be able to use the container as-is, so if changing the build user configuration is a no-go, is adding a build_fuse user a viable path?
I have updated the buildah image to not use fuse-overlayfs in rootful mode? Does this help fix your problem?
I have updated the buildah image to not use fuse-overlayfs in rootful mode? Does this help fix your problem?
Dont have the ability to check this week, but my guess is that now both root and non-root mode will not work.
I think we need to diagnose that.
A friendly reminder that this PR had no activity for 30 days.