update load balancer e2e tests for legacy CloudProvider removal about kubernetes

[aojea]

There is no much to discuss in this specific test of LoadBalancers should be able to create an internal type load balancer, it also is only GCE/GKE, not aws

kubernetes/test/e2e/network/loadbalancer.go

Lines 614 to 615 in fd40d68

	f.It("should be able to create an internal type load balancer", f.WithSlow(), func(ctx context.Context) {
	e2eskipper.SkipUnlessProviderIs("gke", "gce")

kubernetes/test/e2e/framework/providers/gce/gce.go

Lines 353 to 362 in fd40d68

	// EnableAndDisableInternalLB returns functions for both enabling and disabling internal Load Balancer
	func (p *Provider) EnableAndDisableInternalLB() (enable, disable func(svc *v1.Service)) {
	enable = func(svc *v1.Service) {
	svc.ObjectMeta.Annotations = map[string]string{gcecloud.ServiceAnnotationLoadBalancerType: string(gcecloud.LBTypeInternal)}
	}
	disable = func(svc *v1.Service) {
	delete(svc.ObjectMeta.Annotations, gcecloud.ServiceAnnotationLoadBalancerType)
	}
	return
	}

kubernetes/test/e2e/network/loadbalancer.go

Lines 714 to 718 in fd40d68

	if framework.ProviderIs("azure") {
	ginkgo.By("switching back to interal type LoadBalancer, with static IP specified.")
	// For a cluster created with CAPZ, node-subnet may not be "10.240.0.0/16", e.g. "10.1.0.0/16".
	base := netutils.BigForIP(subnetPrefix.IP)
	offset := big.NewInt(0).SetBytes(netutils.ParseIPSloppy("0.0.11.11").To4()).Int64()

This test is full of customization, we should remove it

[danwinship]

(If anyone disagrees with the judgements above let's argue it out.)

[aojea]

+1 to your assessment

• LoadBalancers should handle load balancer cleanup finalizer for service [Slow]
  Not clear if the use of the service.kubernetes.io/load-balancer-cleanup finalizer on LB-type services is actually required (as this test asserts) or merely expected

it tests the cloud-provider service controller logic

kubernetes/staging/src/k8s.io/cloud-provider/service/helpers/helper.go

Line 44 in 0e39ca8

LoadBalancerCleanupFinalizer = "service.kubernetes.io/load-balancer-cleanup"

This is our only test of "ingress actually works". (There is a separate non-provider-specific "the ingress API works" test.) In theory we could write a cloud-provider-kind-specific ingress test, but do we want to? Does SIG Network need to provide anything to allow ingress providers to test for conformance? If so, what? Is Ingress testing something that the Gateway WG is better positioned to handle?

there were nginx-ingress tests that were removed #108598 and moved to its own repo https://testgrid.k8s.io/sig-network-ingress-nginx , gateway API has its own conformance and nginx-ingress too

[BenTheElder]

This generally sounds reasonable to me.

Re: tests planned to be removed because they're not suitable for making generic and will stay GCP specific, I'd like to keep track of those outcomes so we can potentially move some of them out of tree versus not running anywhere.

#122828 (comment)

Tests GCE-and-AWS-specific "internal load balancers"

cc @dims, when we have a test that is N+1 cloud providers subject to removal ... we should discuss options

[BenTheElder]

/triage accepted

[danwinship]

• LoadBalancers should handle load balancer cleanup finalizer for service [Slow]
  Not clear if the use of the service.kubernetes.io/load-balancer-cleanup finalizer on LB-type services is actually required (as this test asserts) or merely expected

it tests the cloud-provider service controller logic

Right, the question is: are cloud providers required to use k8s.io/cloud-provider/controllers/service and/or is the finalizer a mandatory element of the CloudProvider API even if they don't use k8s.io/cloud-provider?

[danwinship]

Hm, I missed L7 Scalability GCE [Slow] [Serial] [Feature:IngressScale] Creating and updating ingresses should happen promptly with small/medium/large amount of ingresses. In theory that is not GCE-specific but I guess it's been there, and been GCE-specific since 2018, and Ingress is deprecated anyway, so I guess there's no point in trying to genericify it?

[tosi3k]

https://testgrid.k8s.io/sig-release-master-informing#gce-master-scale-correctness fails consistently on some of the tests that are mentioned here since Apr 20th and alerts the scalability oncall.

I see #124420 is opened but didn't receive much love for a week already.

Is more discussion needed here about what tests we want to remove?

We could also simply filter those tests out in a CI job config in the meantime.

CC @wojtek-t

[danwinship]

I see #124420 is opened but didn't receive much love for a week already.

It's marked hold because we want thost tests to get moved somewhere gce-specific so we don't regress in coverage. Though, I guess, if they're already failing with the current state of k/k there's no real reason to keep them...

Looking at the testgrid output though, it doesn't really look like "some tests fail consistently since 4/20", it looks like "multiple tests have been failing at increasing rates for a while, several of which happen to have failed in every run since 4/20".