-
Notifications
You must be signed in to change notification settings - Fork 39.8k
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
Ingress API: rework the ingressClassName API documentation #109293
Ingress API: rework the ingressClassName API documentation #109293
Conversation
cc @maelvls |
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
/remove-sig api-machinery |
/test pull-kubernetes-e2e-kind-ipv6 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -305,13 +305,13 @@ type IngressSpec struct { | |||
// IngressClassName is the name of an IngressClass cluster resource. Ingress | |||
// controller implementations use this field to know whether they should be | |||
// serving this Ingress resource, by a transitive connection | |||
// (controller -> IngressClass -> Ingress resource). Although the | |||
// (controller → IngressClass → Ingress resource). Although the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know it's allowed, but I'd prefer to keep the comments ASCII if we can
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sftim requested to use those, but I don't really mind to change it again ^^
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'd be good to codify this sort of thing in review guidelines and perhaps even CI tests.
For the rendered API docs, arrows are better than ASCII art. In source code, maybe we're worried about compatibility with older OSs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the arrows here, I'm fine with either approach. I hadn't spotted the ASCII-comments-only restriction.
Thanks @iamNoah1! /lgtm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: iamNoah1, maelvls, 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 |
What type of PR is this?
/kind documentation
/sig network
What this PR does / why we need it:
This PR is following up #107675 and adds a suggestion for improving the API docs.
Does this PR introduce a user-facing change?