Migrate private registry e2e tests away from gcr.io/k8s-authenticated-test

[spiffxp]

Part of umbrella to migrate kubernetes e2e test images/registries to community-owned infrastructure: kubernetes/k8s.io#1458

Followup to #97002

The registry is used by the following kubernetes e2e tests:

• [sig-apps] ReplicaSet should serve a basic image on each replica with a private image
• [sig-apps] ReplicationController should serve a basic image on each replica with a private image

kubernetes/k8s.io#1459 covers setting up a community-owned alternative

This issue covers updating the tests. Fixes may need to be cherry-picked back to previous release branches.

[spiffxp]

/sig apps
test owner
/sig testing
/sig release
/area release-eng
/wg k8s-infra

[spiffxp]

/triage accepted
/priority important-soon

[spiffxp]

It's worth reconsidering whether these test have value as currently written

kubernetes/test/e2e/apps/rc.go

Lines 68 to 73 in a744bdd

	ginkgo.It("should serve a basic image on each replica with a private image", func() {
	// requires private images
	e2eskipper.SkipUnlessProviderIs("gce", "gke")
	privateimage := imageutils.GetConfig(imageutils.AgnhostPrivate)
	TestReplicationControllerServeImageOrFail(f, "private", privateimage.GetE2EImage())
	})

:

• if someone mirror this image into a public registry, they'll still pass
• they don't run unless the e2e test framework's provider is gce or gke; practically speaking this is only going to run against clusters created by cluster/kube-up.sh

I would be in favor of deleting the tests. They're testing out that a cluster's nodes have been configured to pull from a known private registry, without the use of ImagePullSecrets. That's pretty cluster-implementation-specific.

[spiffxp]

/sig node
I think node may be a more appropriate test owner for this functionality if we decide we want the test to stick around

[desponda]

@spiffxp do you know if this is still targeted to 1.21 Milestone?

[spiffxp]

Yes. This is subject to Test Freeze, not Code Freeze. If we find it's unreasonable to land by then, I'll push to next cycle.

[palnabarun]

@spiffxp -- friendly heads up, Tomorrow March 24th Wednesday is the v1.21 Test Freeze. :)

[spiffxp]

/milestone v1.22

[harshitasao]

Hi @spiffxp, k8s 1.25 Bug Triage Shadow here, just checking in to see if this is still on track for k8s 1.25?
Thank you.

[harshitasao]

Hi, just checking in to see if this is still on track for k8s 1.25?
Thanks!

[helayoty]

@dims 👋 the release 1.25 bug triage Lead. I'm reaching out to see the status of this issue and if we are still targeting the current release.

[dims]

/milestone v1.26

kick the can down the road yet again!

[salaxander]

Hey @dims and @spiffxp - 1.26 bug triage team here! Just wanted to check in and see how we're looking for this release?

Thanks!

[dims]

/milestone v1.27

kick the can down the road yet again! :) thanks for the ping @salaxander

[k8s-ci-robot]

@dims: The provided milestone is not valid for this repository. Milestones in this repository: [next-candidate, v1.16, v1.17, v1.18, v1.19, v1.20, v1.21, v1.22, v1.23, v1.24, v1.25, v1.26]

Use /milestone clear to clear the milestone.

In response to this:

/milestone v1.27

kick the can down the road yet again! :) thanks for the ping @salaxander

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.

[k8s-triage-robot]

The Kubernetes project currently lacks enough 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:

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

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

/lifecycle stale

[furkatgofurov7]

Hey @spiffxp - 1.27 Bug Triage Team Shadow here!

Just wanted to check if this is still on track for 1.27 release?

Thanks!

@dims: The provided milestone is not valid for this repository. Milestones in this repository: [next-candidate, v1.16, v1.17, v1.18, v1.19, v1.20, v1.21, v1.22, v1.23, v1.24, v1.25, v1.26]

Use /milestone clear to clear the milestone.

@dims Hi! Looks like the milestone was not properly applied in your previous comment, should we re-apply it?

Thanks!

[dims]

@furkatgofurov7 let's leave it as-is (not apply milestone at all)

[k8s-triage-robot]

This issue is labeled with priority/important-soon but has not been updated in over 90 days, and should be re-triaged.
Important-soon issues must be staffed and worked on either currently, or very soon, ideally in time for the next release.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Deprioritize it with /priority important-longterm or /priority backlog
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[k8s-triage-robot]

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

This bot triages un-triaged issues 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:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[k8s-triage-robot]

This issue is labeled with priority/important-soon but has not been updated in over 90 days, and should be re-triaged.
Important-soon issues must be staffed and worked on either currently, or very soon, ideally in time for the next release.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Deprioritize it with /priority important-longterm or /priority backlog
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted