Expected Behavior
When we report that a Route is Ready, it should be accessible through Ingress.
Actual Behavior
However, after we create a VirtualService there is some delay before it routes are working and currently the v1alpha3 API doesn't provide a good way to know when (istio/istio#882).
As a stop-gap we could add a special route in our VirtualService that always return the Route/VirtualSerice version. Then when Routes change we can add a prober Pod to probe all ingress pods to make sure that all ingress Pods are seeing updated version of the Routes and mark them with IngressReady condition.
This way users (and integration tests) can start relying on Route.Status more. When istio/istio#882 is fixed we simply replacing these probers by the newly provided mechanism.
Additional Info
This will also remove some of the Polling/Probing noted in #1178
Expected Behavior
When we report that a Route is Ready, it should be accessible through Ingress.
Actual Behavior
However, after we create a VirtualService there is some delay before it routes are working and currently the v1alpha3 API doesn't provide a good way to know when (istio/istio#882).
As a stop-gap we could add a special route in our VirtualService that always return the Route/VirtualSerice version. Then when Routes change we can add a prober Pod to probe all ingress pods to make sure that all ingress Pods are seeing updated version of the Routes and mark them with
IngressReadycondition.This way users (and integration tests) can start relying on
Route.Statusmore. When istio/istio#882 is fixed we simply replacing these probers by the newly provided mechanism.Additional Info
This will also remove some of the Polling/Probing noted in #1178