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
virtiofs: Run unprivileged without feature gate #10657
Conversation
/ok-to-test |
tests/virtiofs/datavolume.go
Outdated
) | ||
}) | ||
if !libstorage.HasCDI() { | ||
Skip("Skip DataVolume tests when CDI is not present") |
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.
Are the tests expected to run without CDI at all?
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.
No, we skip the test if CDI is not present (that check was already in the test before my changes)
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.
Yes, my question was more aimed at whether KubeVirt tests run at all without CDI. IOW can we expected CDI always to be present when the tests run (without the need for another check or skip, not present is expected to result in failure)? IIRC it is present by default in kubevirtci.
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.
Ohh, I don't know really, maybe this was copy-pasted from tests/storage/datavolume.go
, that was the original location of this test (btw, the first test in that file checks twice per test if the CDI is present, line 91 and 99).
I can remove the check if is unnecessary
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.
Are these tests only intended for this CI or also for someone who does not have/needs CDI?
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.
I can only speak for CNV where CDI is present in downstream tests.
890c0cc
to
3ca05dc
Compare
3ca05dc
to
24d357e
Compare
} | ||
config, _, kvInformer := testutils.NewFakeClusterConfigUsingKV(kv) | ||
|
||
enableFeatureGate := func(featureGate string) { |
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.
Not for this PR, but we should really use a common function for doing this
The change looks good to me |
24d357e
to
ca74377
Compare
ca74377
to
8e9ad37
Compare
/retest-required |
8e9ad37
to
757ec2e
Compare
/retest-required |
1 similar comment
/retest-required |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alicefr 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 |
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
Looks good to me, leaving hold in place to give @xpivarc a chance to look at it.
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.
I am a little bit worried that this will give the wrong impression that you could share any volume. Can we clarify this in the PR description + release note?
Currently, virtiofsd can only run unprivileged for sharing ConfigMaps, Secrets, etc., so requiring the feature gate `ExperimentalVirtiofsSupport` enabled, to be able to share PVs. Let's remove that restriction, making possible to share PVs using unprivileged virtiofsd if the feature gate is disabled. This has some limitations, for instance virtiofsd cannot switch the uid/gid. Signed-off-by: German Maglione <gmaglione@redhat.com>
757ec2e
to
8573154
Compare
Do you mean block PVs?, if so, is it enough calling them "filesystem PVs"? |
Yes, the filesystem PVs sound good. What I am more worried about is the privileges issue, users need to be aware there is a limitation to it. |
We plan to update the documentation, with all the limitations, as soon this PR is merged |
Would you mind posting placeholder PR? |
/retest-required |
Done: kubevirt/user-guide#734 |
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.
/hold cancel
/retest-required |
2 similar comments
/retest-required |
/retest-required |
@germag: The following test failed, say
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. I understand the commands that are listed here. |
What this PR does / why we need it:
Currently, virtiofsd can only run unprivileged for sharing ConfigMaps, Secrets, etc., but to be able to share filesystem PVs requires the feature gate
ExperimentalVirtiofsSupport
.This PR removes that restriction, making it possible to share filesystem PVs using unprivileged virtiofsd if the feature gate is disabled, and continue running as root if the feature gate is enabled. So this change doesn't affect users that are already running a privileged virtiofsd.
Running virtiofsd without privileges has some limitations, for instance, virtiofsd cannot switch uids/gids so all the new files created inside the PV will be owned by the same uid/gid (the virtiofsd uid/gid) regardless of the uid/gid of the process that created them inside the VM. After the merge, all the limitations and workarounds will be documented (see kubevirt/user-guide#734).
Signed-off-by: German Maglione gmaglione@redhat.com
Tested-by: Javier Cano Cano jcanocan@redhat.com
Release note: