Restructure IngressClass e2e tests for potential Conformance bump

[cmluciano]

What happened:

The existing ingressclass make assumptions about no default ingressclass being present and they should be run in Serial mode.

What you expected to happen:

These tests should be refactored to not make assumptions about the cluster state, so that they can be added to the conformance suite for IngressClass.

J Liggitt suggests the following changes need to happen:

• Feature Flag
  • Remove feature flag
  • mark the tests that create a default ingressclass or which depend on there being no default ingressclass as [Serial]
• Refactor default value test test](https://github.com/kubernetes/kubernetes/blob/master/test/e2e/network/ingressclass.go#L45)
  • This test should not make an assumption about no default ingressclasses being present.
• should not set default value if no default IngressClass
  • Refactor test so that it does not assume that the cluster does not already have a default ingressclass
  • Test should run in parallel with other e2e tests or be marked as Serial
• "should prevent Ingress creation if more than 1 IngressClass marked as default"
  • Refactor test so that it is not disruptive for existing clusters. It should also be able to run in parallel with other e2e or be marked as Serial.

How to reproduce it (as minimally and precisely as possible):

Run the tests in an existing cluster with similar ingressclass names, an existing default ingressclass, or in a random order.

Anything else we need to know?:

Environment:

• Kubernetes version (use kubectl version): v1.18
• Cloud provider or hardware configuration: N/A
• OS (e.g: cat /etc/os-release): N/A
• Kernel (e.g. uname -a): N/A
• Install tools: N/A
• Network plugin and version (if this is a network-related bug): N/A
• Others:

[cmluciano]

/sig network
/assign @cmluciano

[athenabot]

/triage unresolved

Comment /remove-triage unresolved when the issue is assessed and confirmed.

🤖 I am a bot run by vllry. 👩‍🔬

[cmluciano]

/remove-triage unresolved

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[cmluciano]

Related to #93427

[kolyshkin]

This bug is still there even after #93427, we occasionally see it in cri-o tests (see e.g. cri-o/cri-o#4253).

/remove-lifecycle stale

[cmluciano]

@liggitt Do we have precedent for these type of defaulting e2e tests? Is it sufficient to just check if a default exists already and only then try to create one?

[liggitt]

I'm not sure... I don't see storageclasses, or priorityclasses creating defaulting objects in e2e tests

I don't see anything testing priorityclass defaulting in e2e tests

Apps and Storage have e2e tests (but not conformance tests) that depend on a default storageclass existing, and skip them if none exists: https://github.com/kubernetes/kubernetes/blob/release-1.19/test/e2e/framework/pv/pv.go#L821-L827

[cmluciano]

@robscott Do you have any thoughts about not creating the defaults for e2e tests and just skipping if don't exist?

[robscott]

I'd discussed this a bit with @cmluciano on Slack today but just realized I never followed up here. I think these tests are still valuable to have in the e2e suite. I'd hate to not have any coverage for this feature in e2e tests which I think is what we'd end up with if we only ran the tests in clusters that already had a default ingressclass. Maybe in time more environments will actually provide a default ingressclass, but I'm thinking that won't be widespread anytime in the next few months. Maybe the safest option here is to leave this out of conformance and update it to use an existing default class if it exists.

[kolyshkin]

This bug is still there even after #93427, we occasionally see it in cri-o tests (see e.g. cri-o/cri-o#4253).

My bad 🤦, just found out we forgot to skip [Serial] tests.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[cmluciano]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

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.