Skip to content
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

Handle two or more default IngressClasses more cleanly #110974

Merged

Conversation

AxeZhan
Copy link
Member

@AxeZhan AxeZhan commented Jul 6, 2022

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

When there are two or more defaults, choose one based on class name instead of returning an error.
See #110514 for more information.

Which issue(s) this PR fixes:

Part of #110514

Special notes for your reviewer:

Does this PR introduce a user-facing change?

In the event that more than one IngressClass is designated "default", the DefaultIngressClass admission controller will choose one rather than fail.

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:


@k8s-ci-robot k8s-ci-robot added release-note-none Denotes a PR that doesn't merit a release note. size/S Denotes a PR that changes 10-29 lines, ignoring generated files. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Jul 6, 2022
@k8s-ci-robot
Copy link
Contributor

@kidddddddddddddddddddddd: This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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-ci-robot k8s-ci-robot added the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label Jul 6, 2022
@k8s-ci-robot
Copy link
Contributor

Hi @kidddddddddddddddddddddd. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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-ci-robot k8s-ci-robot added the needs-priority Indicates a PR lacks a `priority/foo` label and requires one. label Jul 6, 2022
@thockin thockin self-assigned this Jul 7, 2022
@thockin
Copy link
Member

thockin commented Jul 7, 2022

And fix the title of this PR?

@AxeZhan AxeZhan force-pushed the cleanup/handle-two-default-FooClass branch from 68f233f to 2393e25 Compare July 8, 2022 03:13
@k8s-ci-robot k8s-ci-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Jul 8, 2022
@AxeZhan AxeZhan changed the title Cleanup/handle two default FooClasses Choose the one with an earlier creation time when there are two or more default ingressClasses. Jul 8, 2022
@AxeZhan
Copy link
Member Author

AxeZhan commented Jul 8, 2022

And fix the title of this PR?
@thockin Thanks for your review.I've updated code and added a new unitTest.

@AxeZhan AxeZhan requested a review from thockin July 8, 2022 03:20
expectedClass: nil,
expectedError: errors.NewForbidden(networkingv1.Resource("ingresses"), "testing", errors.NewInternalError(fmt.Errorf("2 default IngressClasses were found, only 1 allowed"))),
expectedClass: utilpointer.StringPtr(defaultClass1.Name),
expectedError: nil,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor: we don't need to set this field to nil - it's just noise

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May I ask which field you are talking about? If it is expectedError, we have to set it to nil,since we no longer return error when there are two or more ingressClasses.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not setting the field, leaving it empty, has the same effect to set it to nil

Suggested change
expectedError: nil,

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but it was already this way, and seems there are other test cases setting it

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes,And I set the field to nil in order to keep the format uniform, should we delete the nil field for all the tests?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would normally argue to remove it all over, but that can be a different PR

@thockin thockin changed the title Choose the one with an earlier creation time when there are two or more default ingressClasses. Handle two or more default IngressClasses more cleanly Jul 8, 2022
@AxeZhan AxeZhan force-pushed the cleanup/handle-two-default-FooClass branch from 2393e25 to 8315dcd Compare July 9, 2022 02:04
Comment on lines +146 to +148
if defaultClasses[i].CreationTimestamp.UnixNano() == defaultClasses[j].CreationTimestamp.UnixNano() {
return defaultClasses[i].Name < defaultClasses[j].Name
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this test cases is missing, two defaults same timestamp, choose the one with the lower name

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this test has already done it.It has two deault classes with createTime equal to 0. I have updated expectedClass field in the commit. I will also update the test name.

@aojea
Copy link
Member

aojea commented Jul 10, 2022

/ok-to-test

@k8s-ci-robot k8s-ci-robot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Jul 10, 2022
@AxeZhan AxeZhan force-pushed the cleanup/handle-two-default-FooClass branch from 8315dcd to 60b18fb Compare July 11, 2022 01:49
@AxeZhan AxeZhan requested review from thockin and aojea July 11, 2022 06:39
@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed release-note-none Denotes a PR that doesn't merit a release note. labels Jul 12, 2022
@thockin thockin added sig/network Categorizes an issue or PR as relevant to SIG Network. release-note-none Denotes a PR that doesn't merit a release note. and removed release-note Denotes a PR that will be considered when it comes time to generate release notes. labels Jul 12, 2022
@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. release-note-none Denotes a PR that doesn't merit a release note. labels Jul 12, 2022
@thockin
Copy link
Member

thockin commented Jul 12, 2022

Thanks!

/lgtm
/approve

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jul 12, 2022
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kidddddddddddddddddddddd, thockin

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 12, 2022
@k8s-triage-robot
Copy link

The Kubernetes project has merge-blocking tests that are currently too flaky to consistently pass.

This bot retests PRs for certain kubernetes repos according to the following rules:

  • The PR does have any do-not-merge/* labels
  • The PR does not have the needs-ok-to-test label
  • The PR is mergeable (does not have a needs-rebase label)
  • The PR is approved (has cncf-cla: yes, lgtm, approved labels)
  • The PR is failing tests required for merge

You can:

/retest

@k8s-ci-robot k8s-ci-robot merged commit 59842a5 into kubernetes:master Jul 13, 2022
@k8s-ci-robot k8s-ci-robot added this to the v1.25 milestone Jul 13, 2022
@aojea
Copy link
Member

aojea commented Jul 14, 2022

@kidddddddddddddddddddddd we forgot to modify the e2e test for this and now is failing constantly
Screenshot_20220713-212034_Chrome

Can you please fix the e2e test?

ginkgo.It("should prevent Ingress creation if more than 1 IngressClass marked as default [Serial]", func() {

@AxeZhan
Copy link
Member Author

AxeZhan commented Jul 14, 2022

kubernetes/test/e2e/network/ingressclass.go

I'll create a pr to fix this and ping you in that pr.

@sftim
Copy link
Contributor

sftim commented Aug 1, 2022

I'm wondering how we'll document this. It feels difficult to explain clearly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. lgtm "Looks good to me", indicates that a PR is ready to be merged. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/network Categorizes an issue or PR as relevant to SIG Network. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants