Relax ingress await restrictions #1832
Conversation
| @@ -212,7 +212,7 @@ func newHelmReleaseProvider( | |||
| } | |||
|
|
|||
| func debug(format string, a ...interface{}) { | |||
| logger.V(3).Infof("[DEBUG] %s", fmt.Sprintf(format, a...)) | |||
| logger.V(6).Infof("[DEBUG] %s", fmt.Sprintf(format, a...)) | |||
There was a problem hiding this comment.
Sneaking this in. Happy to move to a separate PR if necessary.
Does the PR have any schema changes?Looking good! No breaking changes found. |
|
@lblackstone Thoughts on the following?
|
Does the PR have any schema changes?Looking good! No breaking changes found. |
I think it's ok to loosen the behavior unconditionally for now, and we can reevaluate if we get user feedback about it. The result of an error here is most likely just a transient update failure if something downstream gets updated too early. |
Proposed changes
Currently an ingress object is marked available when the backend endpoints are available and when the loadbalancer IP or host is available. The change here relaxes some assumptions made previously around ingress objects only referring to service backends or paths referencing endpoints that would emit events. The loadbalancer still a strict requirement but endpoint checks have been relaxed.
While I think this is the better default behavior, I wonder if we should add an annotation to opt-in to the previous stricter await logic?
Related issues (optional)
Fixes #1810