Check for revision existance when updating traffic

[rhuss]

When the traffic distribution is updated e.g. via

kn service update random --traffic v1=10 --traffic latest=90

and if the revision does not exist (note the typo here with latest instead of @latest, then the update hangs because the service waits for this revision to exists before becoming Ready (but this will be never the case). So either the server should already go into an error state or as this doesn't seem to be the case, the client should refuse to create traffic targets to revisions that do not exist.

[navidshaikh]

Revision existence check was originally planned with traffic splitting implementation (first check list item for #345), but then IIUC we took off that being in scope of server side validation for resource existence (knative/serving#5094). The issue is tagged for serving v0.10.x due Oct 29.

the client should refuse to create traffic targets to revisions that do not exist.

We can introduce this (and deprecate when we've server side validation for this).

[rhuss]

The issue currently is that the long timeout of 10 mins introduced in kn service create and kn service update relies on the assumption that a service goes into False or True for the Ready condition after some time < 10 mins. If it stays in Unknown (as it is now for an unknown revision), it takes really that 10 minutes to timeout.

[akerekes]

Looks like this can be closed as the server-side bug has been fixed?

$ ./kn service update hello --traffic hello-pyzfc-1=30% --traffic latest=70%
Updating Service 'hello' in namespace 'default':

  0.054s The Route is still working to reflect the latest desired specification.
RevisionMissing: Revision "latest" referenced in traffic not found.

[rhuss]

Good point, thanks for the heads up.