Serving: latestRevision routes may point to older revisions if latestCreated is not ready

[greghaynes]

In what area(s)?

/area API

First documented in #5208

If a route is defined within a service with latestRevision: true, and a working revision 1 is created, then a working revision 2 and very quickly afterwards a non-working revision 3 is created the route can end up stuck pointing at revision 1 indefinitely. I would expect the route to end up pointed at revision 2 instead.

per @dgerd - This seems to be due to our exclusive use of latestCreated in the route controller to determine what revision we check for readyness.

[taragu]

/assign

[dgerd]

Some things to consider in fixing this:

(1) Performance - The time to reconcile should not increase proportionally to the number of Revisions. I have a feeling the current implementation is selected to avoid doing a list and sort of all Revisions.
(2) Race Conditions - The latestReady revision should not move backwards. For example if an earlier Revision becomes "Ready" after a later Revision, or if two Revisions attempt to update at the same time.

[mattmoor]

I think the simplest change would be to make this function return the sorted list of revisions with generations in the range: [metadata.generation, latestReadyRevision's config generation).

I'm not especially concerned about the performance of this since it should be entirely based on the informer cache, and typically a very short list to sort (actually probably empty in most cases).

[dgerd]

Given the complexity of this change lets push to 0.11.x.