kn client report timeout and the kn service is ready

[cdlliuy]

Currently, we are running with kn client v0.13.1 and knative 0.13 as well.

kn version
Version:      v0.13.0
Build Date:   2020-03-11 11:01:19
Git Revision: db569fa
Supported APIs:
* Serving
  - serving.knative.dev/v1 (knative-serving v0.13.0)

When running kn client, sometimes I noticed kn reported timeout , but the underneath ksvc's status is ready.

See below example:
with cmd1: kn client report to timeout after 295 seconds since [2020-04-26 14:01:48.81 (UTC)]
with cmd2: we can see the ksvc was ready
with cmd3: the route ready happened at 2020-04-26T14:02:46Z , which is shorter than 295s.

[2020-04-26 14:01:48.81 (UTC)]> kn service create e2e-test-3-knservice-609f591f --image xxx --wait-timeout 295 --env TARGET=revision1 -n 2e07cf8c-c42b
Creating service 'e2e-test-3-knservice-609f591f' in namespace '2e07cf8c-c42b':

  3.083s The Route is still working to reflect the latest desired specification.
  4.125s ...
  4.125s Configuration "e2e-test-3-knservice-609f591f" is waiting for a Revision to become ready.
  7.644s ...
  8.724s Ingress has not yet been reconciled.
timeout: service 'e2e-test-3-knservice-609f591f' not ready after 295 seconds


+ kn -n 2e07cf8c-c42b service describe e2e-test-3-knservice-609f591f
Name:       e2e-test-3-knservice-609f591f
Namespace:  2e07cf8c-c42b
Age:        4m
URL:        http://e2e-test-3-knservice-609f591f.2e07cf8c-c42b.xxxxx

Revisions:  
  100%  @latest (e2e-test-3-knservice-609f591f-gkvlp-1) [1] (4m)
        Image: xxxx (pinned to 7b3ce1)

Conditions:  
  OK TYPE                   AGE REASON
  ++ Ready                   3m 
  ++ ConfigurationsReady     4m 
  ++ RoutesReady             3m 

+ kubectl -n 2e07cf8c-c42b get ksvc e2e-test-3-knservice-609f591f -o json
+ jq .status.conditions
[
  {
    "lastTransitionTime": "2020-04-26T14:01:55Z",
    "status": "True",
    "type": "ConfigurationsReady"
  },
  {
    "lastTransitionTime": "2020-04-26T14:02:46Z",
    "status": "True",
    "type": "Ready"
  },
  {
    "lastTransitionTime": "2020-04-26T14:02:46Z",
    "status": "True",
    "type": "RoutesReady"
  }
]


+ kn -n 2e07cf8c-c42b route describe e2e-test-3-knservice-609f591f
Name:       e2e-test-3-knservice-609f591f
Namespace:  2e07cf8c-c42b
Age:        4m
URL:        http://e2e-test-3-knservice-609f591f.2e07cf8c-c42b.us-south.knative.test.appdomain.cloud
Service:    e2e-test-3-knservice-609f591f

Traffic Targets:  
  100%  @latest (e2e-test-3-knservice-609f591f-gkvlp-1)

Conditions:  
  OK TYPE                  AGE REASON
  ++ Ready                  3m 
  ++ AllTrafficAssigned     4m 
  ++ IngressReady           3m 
  

yes, Our knative environment is suffering some performance issues, so kn service create sometimes is slow, but I wonder why the timeout in above case is not honest enough?

[daisy-ycguo]

@cdlliuy is it a local network problem ? I mean, if the local network is not stable, it may cause the issue.

If there is a way to reproduce the issue, we could look into it.

[rhuss]

I don't think it's a network issue. Could you please try with 0.13.2 and/or 0.14.0 ? We had a fix for a similar issue but this fix is supposed to be included in 0.13.0 already.

Also, does this issue all the time or only sporadically ?

[cdlliuy]

@rhuss , it is sporadically .
we did have several ingressnotconfigured errors when creating knative services at the end of the designed timeout, but when analyzing all the timeout failures , we found above un-honest timeout cases mixed inside.
Also, given the commit version of v0.13.0 is db569fa, I think the mentioned fix did included already.

[MIBc]

Can you show the ksvc created time in k8s.
We need to make sure time synchronization between client side and k8s cluster.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[cdlliuy]

The error was seen more recently and will provide logs as required

[rhuss]

Ok,

let's keep the issue open. @cdlliuy please let me know if you have more information about it

/remove-lifecycle stale

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.