Open aslafy-z opened 2 years ago
/good-first-issue /help-wanted /triage accepted /priority backlog
@strongjz: This request has been marked as suitable for new contributors.
Please ensure that the issue body includes answers to the following questions:
For more details on the requirements of such an issue, please see here and ensure that they are met.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue
command.
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
Hello guys, I would like to work on this issue, can you give me more details on what exactly I need to do?
/assign
/unassign
/assign
/unassign
Hi @strongjz and @aslafy-z , I am new to this repository and still trying to understand the workflow of the project, could you help me figure out what to do in this issue?
/assign
@aslafy-z tht annotation is named aptly and does what it is names as.
If you are looking for a new feature to handle a case where no existing ingress rule matches a incoming http request and as a result instead of the default-backend of the project handling the response, you want your own behaviour, then I think the documented procedure is to create your own image and use that to create a backend to be configured as a default-backend.
Changing an existing annotation that is sort of not named after your desired behaviour does not seem like an improvement. There are several such changes made earlier that has led to unmaintained and unsupportable features and the project is now in a 6 month phase to clean up and stabilize the code.
This is my opinion so lets wait for other comments. But I vote for not doing this change you are proposing. I hope the project steers away from such changes that only one user benefits from and that is not deeply thought over and elaborated.
But I am not a developer so I could be wrong so lets hope there is enough info posted here about a deep dive analysis on how the change you propose is a improvement for a large number of users.
Here's my use case, the platform team offers a nginx ingress controller with a company-branded default-backend and handles 500 errors by default. Some apps may want to overwrite this behavior by disabling the company default-backend all-together for their ingress (e.g.: development phases where they want to see their app outputs even if they are errors).
Allowing users to set nginx.ingress.kubernetes.io/custom-http-errors: off
might do the trick.
Another way would be to add a new annotation like nginx.ingress.kubernetes.io/disable-default-backend: 'true'
.
I feel like it would be a great addition but I understand your point, let's keep this issue open and see if it gains traction.
/unassign
/assign
I would like to work on this issue. As I am completely new to this workflow, can I please get some guidance on how to go about working on this issue ?
There's an open pull request that address this issue.
/assign
When
nginx.ingress.kubernetes.io/custom-http-errors
is set to stringoff
, overwrite the configmap value with an empty list instead of skipping it.My current work-around is to use the
418
HTTP code (nginx.ingress.kubernetes.io/custom-http-errors: "418"
) because my apps aren't using it :wink: