-
Notifications
You must be signed in to change notification settings - Fork 115
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
Create Ingress awaiter with incremental status updates #283
Conversation
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'm voting to approve because it is very similar to what we're doing for Service
, and because it's covered well by tests.
pkg/await/extensions_ingress.go
Outdated
config createAwaitConfig | ||
ingress *unstructured.Unstructured | ||
ingressReady bool | ||
ingressClient *dynamic.ResourceInterface |
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.
We're doing this because of initializeClient
right? I tend to find this awkward. Because we are using the client pool under the covers, it doesn't seem that bad to always just create the client any time that method is called.
pkg/await/extensions_ingress.go
Outdated
ingressWatcher, endpointWatcher watch.Interface, timeout <-chan time.Time, | ||
settled chan struct{}, | ||
) error { | ||
iia.config.logStatus(diag.Info, "[1/3] Waiting on endpoints for each Ingress path") |
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.
In the Service
we chose to phrase this along the lines of "service must target pods". I think this is important to keep because many of our users do not know what endpoints are.
I did address the feedback, but since it was already approved anyway, and tests are passing, will merge now. |
Fixes #287