Error Message if Namespace Does Not Exist With -n Flag

[danielhelfand]

Expected Behavior

If a namespace is provided that does not exist for any command that uses -n, the cli should notify the user the namespace does not exist. Simply listing that no items were found is misleading and may make the user think there are no items in the namespace.

Actual Behavior

$ tkn task ls -n doesnotexist
No tasks found

$ tkn pr ls -n doesnotexist
No pipelineruns found

Steps to Reproduce the Problem

1. Run any command that uses -n (e.g. tkn tr ls) and enter a namespace that does not exist

[chmouel]

/kind bug

[chmouel]

I believe this is fixed in 2efd4e7

@danielhelfand feel free to reopen if there was more to it

/assign @danielhelfand
/close

[danielhelfand]

/reopen

2efd4e7 addressed #308, but did not address this issue. I can pick it up and look into it later this week or next.

[tekton-robot]

@danielhelfand: Reopened this issue.

In response to this:

/reopen

2efd4e7 addressed #308, but did not address this issue. I can pick it up and look into it later this week or next.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[chmouel]

Sounds good! thanks

[afrittoli]

To be fair this is the same behaviour kubectl exposes - it just applies a filter and returns what matches. For instance in my cluster, if I filter by a non-existing namespace, I get cluster-wide resources:

$ kubectl get all -n foobar


NAME                                                               READY   REASON
clusterchannelprovisioner.eventing.knative.dev/in-memory           True
clusterchannelprovisioner.eventing.knative.dev/in-memory-channel   True

NAME                                                                                        READY   REASON
clusteringress.networking.internal.knative.dev/route-4bdb4e0b-6129-11e9-b22c-165770ee2c86   True
clusteringress.networking.internal.knative.dev/route-696e0dff-5afe-11e9-91a2-42406a53c343   True
clusteringress.networking.internal.knative.dev/route-6a3fb797-5afe-11e9-91a2-42406a53c343   True
clusteringress.networking.internal.knative.dev/route-7b36407a-50b4-11e9-8ed0-7a2460b12a0e   True
clusteringress.networking.internal.knative.dev/route-a981cb46-50b3-11e9-8ed0-7a2460b12a0e   True
clusteringress.networking.internal.knative.dev/route-aaca4ee9-50b3-11e9-8ed0-7a2460b12a0e   True

[danielhelfand]

@afrittoli It's definitely consistent with kubectl, but my thought was this could be an area that tkn could improve on. As you mentioned in #316, I wouldn't want a true error to be returned. Just a stdout message about the namespace not existing. I think it's helpful to not present resources or lack thereof if what is being searched for doesn't exist. Certainly, someone who is familiar with kubectl can understand if something doesn't look right, but I have always thought it's one of those strange behaviors with kubectl that I never quite understood.

[chmouel]

Can we close this since #316 has been merged ? This is the last PR to get in before 0.4.x release

[danielhelfand]

#316 dealt with the error message for a pipeline name not existing in a particular namespace. There hasn't been a fix for this yet.

[chmouel]

ah thanks, i'll leave this open and hopefully this will get it for release 0.5.x

[danielhelfand]

@chmouel Yeah, apologies. I fell behind on other things this week and lost track of this one. Think 0.5 shouldn't be a problem.