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

"Ignore update for invalid class" misleading log #3768

Closed
paovitali opened this issue Feb 15, 2019 · 0 comments · Fixed by #3771
Closed

"Ignore update for invalid class" misleading log #3768

paovitali opened this issue Feb 15, 2019 · 0 comments · Fixed by #3771

Comments

@paovitali
Copy link

Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/.): No

What keywords did you search in NGINX Ingress controller issues before filing this one? (If you have found any duplicates, you should instead reply there.): ingress.class, ignoring updates

NGINX Ingress controller version: 0.22

Kubernetes version (use kubectl version): 1.10.5

Environment: Bare Metal

  • Cloud provider or hardware configuration: Bare Metal
  • OS (e.g. from /etc/os-release): Ubuntu 16.04.3 LTS
  • Kernel (e.g. uname -a): 4.4.0-109-generic
  • Install tools: Puppet

What happened: Starting from 0.22 release, in raw-app logs I see at every reload/nginx change an INFO log line stating store.go:393] ignoring ingress <ingress-app> based on annotation kubernetes.io/ingress.class for each NS.

This line appears even if NO "ingress.class" annotations are set in any of k8s ingress objects and NO "ingress-class" controller argument deployment flag is set, condition that should be considered as "valid" in the check for annotations.

What you expected to happen: When the "ingress.class" annotation is not used this log line should not appear or it should have a dedicated different message like No changes on ingress for < NS > - skipping update. Also it would be a nice to have to make this log configurable (if not already possible)

How to reproduce it (as minimally and precisely as possible): Just fire up a 0.22 release in a cluster with no "ingress.class" settings in both rules/controller.

Anything else we need to know: This is the PR that included that new log line #3532

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant