Closed dsimansk closed 7 months ago
For scenario 1, I guess or udpdate the kn client
won't help :-)
For scenario 1, I guess
or udpdate the kn client
won't help :-)
Yep, fixed the proposed errors.
/assign @xiangpingjiang
@dsimansk Hello, David
To resolve this issue, my idea is when client gets an no or newer Knative Serving API found on the backend
error, client need to get all knative crds installed in the cluster, if there is a crd same with requested resource but different version, the error becomes incompatible Knative Serving API found on the backend
, otherwise the error becomes no Knative Serving API found on the backend
.
Do you think is it ok ?
Sounds good, I think you can get over the /apis
endpoint and I also think its good enough to check whether there is a KService resource in any version, then --> "no Knative API found", otherwise just assume that that there is a version mismatch (the only other possible error),. so no need to really check the version.
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
.
/remove-lifecycle stale
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
.
Feature request
In the current implementation when
kn
is unable to query Knative resource, we display combined "no or newer" error on missing API or incompatible API.Per feedback from users, that might be confusing how to approach the troubleshooting of such issue with the Knative installation.
Use case
There are 2 main scenarios to cover:
v1alpha1
and therefore backend xkn
mismatch./cc @rhuss