Re: [Action Required] e2e Test Improvements in 1.34

7 views
Skip to first unread message

Benjamin Elder

unread,
May 6, 2025, 6:55:54 PMMay 6
to Rodrigo Campos, dev, kubernetes-sig-testing
Sorry this went to spam (!)

cc also sig-testing for specific testing questions.

> So shall I add a:
>
>framework.WithFeatureGate(feature.UserNamespacesSupport)
>? That is all, I guess?

Probably yes.

If your tests didn't have other requirements besides the feature gate then you would clean up and remove the test/e2e/feature.

This test seems to require host settings that are not universally available, and won't benefit as much from this as feature work that only requires featuregates.

Passing WithFeatureGate is still recommended, that will allow us to more accurately track and select the tests.

If for example, we decided that we can safely assume userns is widely enabled now, then it would make sense to just rely on this featuregate (and possibly the self-skip discussed below).

> What we are doing currently is skip these specific tests if the node
isn't properly configured with a custom kubelet userns mapping
configuration:
https://github.com/kubernetes/kubernetes/blob/893486dfd16ff8c628c6f33bb2bea869ad86115f/test/e2e/common/node/security_context.go#L132-L137
>
> Shall this be migrated to cluster e2e features? In that case, is this
> planned already? Or do you have any pointers on how that should be done?

Using a cluster e2e feature would be reasonable, but if you think kubeletUsernsMappings is a 100% reliable portable detection then that's OK,
self-skip can be more ergonomic, at the risk of inaccurate skipping.

Conformance tests cannot self-skip, but this feature seems unlikely to be part of conformance anyhow.

Hope that helps, feel free to ping me in slack or github as well for follow-ups.

On Mon, May 5, 2025 at 7:10 AM Rodrigo Campos <rod...@sdfg.com.ar> wrote:
On 4/28/25 5:00 PM, 'Benjamin Elder' via dev wrote:
> Hello Kubernetes contributors! Late in 1.33 we landed improvements
> <https://github.com/kubernetes/kubernetes/pull/130908>to the e2e
> framework that you should adopt for your 1.33+ tests, Action Required:
>
>
>  1.
>
>     If your e2e test is related to feature gated functionality pass the
>     k8s.io/kubernetes/pkg/features <https://github.com/kubernetes/
>     kubernetes/blob/master/pkg/features/kube_features.go>featuregate
>     like framework.WithFeatureGate(features.DeclarativeValidation)to the
>     test. The featuregate details including Alpha/Beta/GA/Deprecated and
>     OffByDefault will be communicated to the test framework and runners
>     as ginkgo labels.
>     If your test is related to multiple featuregates, pass each of them.


Hi Ben, sorry for the question, but it's not 100% clear to me what to do.

For example, I have this test:
https://github.com/kubernetes/kubernetes/blob/893486dfd16ff8c628c6f33bb2bea869ad86115f/test/e2e/common/node/security_context.go#L93

How shall it be adapted?

The `feature.UserNamespacesSupport` comes from:
https://github.com/kubernetes/kubernetes/blob/893486dfd16ff8c628c6f33bb2bea869ad86115f/test/e2e/feature/feature.go#L531

So basically, it is already expanded to:

UserNamespacesSupport =
framework.WithFeature(framework.ValidFeatures.Add("UserNamespacesSupport"))


So shall I add a:

framework.WithFeatureGate(feature.UserNamespacesSupport)
? That is all, I guess?


>  2.
>
>     If your test depends on a cluster e2e “feature” <https://github.com/
>     kubernetes/kubernetes/blob/master/test/e2e/feature/feature.go>such
>     as a “LoadBalancer”, continue passing features.LoadBalancer(k8s.io/
>     kubernetes/test/e2e/feature <http://k8s.io/kubernetes/test/e2e/
>     feature>). This includes any special configuration (e.g. IPv6 or
>     DualStack) or additional components (LoadBalancer) that we cannot
>     assume all clusters have available/configured by default that are
>     not merely enabling feature gates.

I _think_ for userns we are using a cluster e2e feature (the
features.UserNamespacesSupport) to run them in nodes that the stack has
all that is required for userns. So I _think_ that part is probably okay.

However, we do have one node with special configuration to test the case
that the node is configured to use a specific mappings (instead of the
default) for userns. Tests on that node are scheduled to run
periodically. We can run manually using: /test
pull-kubernetes-node-crio-cgrpv2-userns-e2e-serial

What we are doing currently is skip these specific tests if the node
isn't properly configured with a custom kubelet userns mapping
configuration:
https://github.com/kubernetes/kubernetes/blob/893486dfd16ff8c628c6f33bb2bea869ad86115f/test/e2e/common/node/security_context.go#L132-L137

Shall this be migrated to cluster e2e features? In that case, is this
planned already? Or do you have any pointers on how that should be done?
Reply all
Reply to author
Forward
0 new messages